Closed tejHackerDEV closed 1 year ago
@SchabanBo, please check the PR #91 which adds the feature that I suggested above
I had this idea before, I even added it. But then I release, this could lead this package to be something like getx in the future. Which I don't want to. The package should be just about navigation and nothing else. And the developer can choose how to use it. So now in my projects I am using this with get_it for DI and now for every new project I just add this for defining the locator and this middleware for init/dispose the controller.
Ya I too get that point but if you see GetX is lot more other than this. But I think we can exclude DI but you can keep controller. Because If you look into AndroidDevelopment there is an ViewModel concept where the business will present & it will be bind to the UI. So I think we can include the controller as a ViewModel & bind it to that particular navigated page. So In my opinion controller should be included in the package
Ok, as long as the QController is not linked to code, it will be cleaned with the tree shaking anyway if the developers done not use it. Can you please update the PR for that?
I agree with the OP that there should at least be a controller. I have in the past few days been building a declarative router and fighting off and on with getting the router to rebuild properly with a GetX observable etc. and it would be nice if there were a controller to go with the declarative router to accomplish it simply with a stateless widget and Rx a'la GetX.
@SchabanBo, This weekend for sure I will work on the PR & update it. And can you add me as a maintainer as we discussed before?
I just realized that we cannot use this middleware because it references another class (get_it). @tejHackerDEV an invitation was sent to you.
Hi @SchabanBo, in an order to support ViewModel concept, I created an extra add-on to the qlevar package. Because I feel it shouldn't be bind into the package. It should be published as an add-on (that's what I feel). But in case if you want to merge it into the package, I am happy for that too.
And I here is the add-on that I am speaking about. Go though it once added the example too. If you feel its ok then we can create a new package under qlevar account in pub.dev & pushlish this one too. As of now not added any tests but will add it in future.
That is a great Idea, so we could leave qlevar router just for navigation, and we can add write about this concept in the README. And if anyone would like to use it, can use the add-on. What do you need from me now?
What I want is to publish this add-on on pub.dev we need to create one more package under qlevar account to add this to the qlevar family
@SchabanBo any update on this?
Not yet, last week I moved to new apartment and I need some time before I could do anything.
Not an issue @SchabanBo, take you time & congratulations for moving into newer apartment
@tejHackerDEV The first version is live. Maybe you could add a link to QVM in the README of qlevar_router.
@SchabanBo sure, thanks
yes will nice feature.
Hi @SchabanBo, Thanks for the package it pretty much reduces the headache of Navigator 2.0 concepts & abstract away the complexities of it. But I think package should have some DI (which will greatly helpful while developing apps) & Yes we have great libraries out there for handling DI but using them at some point of time we will get into some issues like we have seen in #86.