Making dependency injection as separate package

[HosamHasanRamadan]

I think that that states_rebuilder dependency injection is the most complete option for flutter cause it covers most use cases. But what keeps me away from it that states_rebuilder tries to do so many like get package like routing , animation, dependency injection…etc it is like whole framework So my suggestion is decouple each feature to its own package and keep it simple and clean . Thank you for your amazing work .

[amoslai5128]

@HosamHasanRamadan Do you mean putting the form, routing, animation, etc to an independent package called states_rebuilder_services something like that?

Still, the size of this library is pretty small, and the DI (injection) covers most of the features (like form, text field, even scrolling), personally, I enjoyed it very much that's all in one, what do u think @GIfatahTH ?

[GIfatahTH]

Thank you @HosamHasanRamadan for your proposition.

Theoretically, States_rebuilder can be divided into three packages:

• Core States_rebuilder: states management and dependency injection (with all InjectedFoo objects);
• Route management;
• Animation. (I have a library called Animator based on States_rebuilder)

What keeps me from dividing States_rebuilder into three libraries is the low maintenance cost and the small size of the library.

Because you mentioned the getX library, I'm saying that getx is supposed to be a micro framework, for this purpose Getx hides a lot of Flutter widgets and exposes a simple API to the user. This will certainly make the developer's life easier, but on the other hand, it increases the maintenance cost for the maintainer of getx and ends up making the Flutter style a little weird for a developer accustomed to using getX.

On the other hand, in states_rebuilder, I follow the saying that goes "Give the bread dough to the baker even if he eats half of it". The UI baker here is Flutter. We read on the Flutter homepage: "Flutter is Google's UI toolkit for building, ..."

For this reason, states_rebuilder does not draw a single pixel on the screen. States_rebuilder only offers widgets that maintain state.

For example to show a SnackBar without context: RM.scaffold.showSnackBar(SnackBarWidget());

The only thing States_rebuilder does here is maintaining the ScaffoldState to allow the developer to display SnakeBar without the need for BuildContext.

It is up to the developer to define SnackBarWidget using the Flutter style or using other libraries.

The same can be said for OnFormFieldBuilder and other injected states.

Regarding the size of the library, for each new feature (Foo) I add, I only need to define three classes:

• Abstract InjectedFoo class
• InjectedFooImp class implementing the abstract class
• and an OnFooBuilder widget to listen to the InjectedFoo

Moving the Foo feature to a separate library forces me to make a lot of private APIs public that I don't like.

For example, for the Animation feature, I added InjectedAnimation, InjectedAnimationImp, and OnAnimationBuilder classes with some Data classes.

Anyway, I don't think you have to use all the features in the library, you can use the part you like.

[amoslai5128]

@HosamHasanRamadan Please check out the PR #258

[GIfatahTH]

Now Navigation is set to its separated package.

https://github.com/GIfatahTH/navigation_builder