Why not Riverpod to begin with

There’s just so many reasons. Here’s some off the top of my head:

  • Steep learning curve
  • Sheer number of providers to choose from
  • Unsatisfying developer experience
  • Icky amounts of code generation
  • Extremely opinionated

Why Creator

Creator simplifies your state management base to just 2 building blocks: Emitter and Creator.

Creator is for holding a piece of synchronous state, and Emitter for asynchronous.

When you need a widget to update on the screen, you wrap it inside a Watcher, and watch whatever piece of state you want to trigger that widget’s rebuilds to depend on. When that state updates, whether you’re using it in that widget or not, the Watcher will rebuild.

In order to manipulate any piece of state, you just need access to a Ref, and a ref is always accessible through the current BuildContext, like so - context.ref.

You need to wrap your MaterialApp in a CreatorGraph.

That’s it. There’s no need to break your head over what Provider to choose, no build_runner process to execute, nothing extra to remember and god, no fixed ways to do things. You’re free to use the state management primitives as you see fit. Want to manage states in individual classes? Sure. Want to handle state on the fly? Why not.

Some background

I come from GetX. The reason I wanted to migrate was because I’d seen a lot of conflicting posts online regarding what sorcery was running behind the scenes of that library. The fact that you can navigate without access to a BuildContext was quite worrying, albeit supremely cool.

I chanced upon a Medium post by the author of the library. What instantly caught my eye was that the core library was only 100 odd lines, and had no external dependencies. Holy. In fact, he went on to explained how it works in that same post.