Learn More
Resend Email
0
Nmeri17
108d

Is using getx's `ever` function a code smell? I'm using getx as a library rather than a framework ie state management instead of wrapping the app in it and using their widgets

My background from writing reactive code in vuex is that whenever a watched variable in the overarching store is updated, it automatically calls its listeners and re-renders the view. However, my flutter widgets remain stagnant except I explicitly mount the ever worker and call setState on a local field basically duplicating the store variable/field. It feels hacky to me tbh and leads to errors about calling setState on non-mounted screens, which I'm circumventing by checking if mounted (another hack)

It feels contrived like Band-aid over an actual problem. Is there a more natural way to propagate changes? I'm neither using getBuilder nor obx cuz a significant portion of my code entails computing stuff rather than just outputting data off an api. I want ui decisions to reside on my statefulWidget rather than migrating them to getx controller

Is this really how the project functions, should it be used a specific way, or am I missing something?

question

mobiledev

flutter

mobileappdevelopment

getx
Favorite
Ranter
Comments
  • 0
    108d
    GetX sucks. You can search 'why is getx hated?' and read up the reasons on reddit. The author is an arrogant prick, and his library is objectively bad because it tries to to everything.

    Navigation? Check.

    Dialog and snackbar? Check.

    Shared preference? Check.

    State? Check.

    Global vars? Check.

    Validate email format??? Check.

    Theme? Check.

    Internationalization? Check.

    Flutter library shouldn't try to do everything. It should focus on one task, so we can easily replace it if the library somehow dies.

    Plus, it is anti pattern and make you dump. The requirement to have context is vital to android development. It enforces you to be a good programmer who's conscious about app life cycles and resource disposal. One shouldn't be proud that he can navigate / show dialog / set state without a need of context.

    Use Riverpod instead for cross widgets states.
  • 0
    108d
    @daniel-wu brother, I read same. My first professional flutter gig used bloc. When I returned to the language, I heard it had been overtaken by riverpod and getx. Compared both using online articles and the opinion seems to lean towards riverpod.

    1) Unfortunately, both the documentation and articles seemed waaay too convoluted for something as TRIVIAL as state management. If I hadn't used bloc before, I'd have thought it was rocket science reactively tracking data fetched from an api. I also hate the magic of its design: I write a function and it autogenerates a duplicate suffixed with "provider". I found it hilarious when they claimed this is even the improved version

    I hate standalone functions so I looked up riverpod classes and it was another lengthy chapter. No shade to the author but this is plain absurd https://codewithandrea.com/articles...
  • 0
    108d
    @daniel-wu

    I wasn't making any headway and time was running out so I had to try out getx. I went through the articles and what I can say is that the alleged disadvantages lack merit tbh. I'm actively repulsed by the devs pulling out cos the library has just one maintainer. I built an open source framework and it blows my mind how a potential user could be turned off by no one else contributing to it. I don't stop anyone from doing so. Why am I "punished" by boycotting? How is it my fault?

    I also disagree that doing too much is a con. Why? My framework, suphle, shares same philosophy
    Because junior devs suck when you let them "wing" it. Wall them through an opinionated structure to guarantee standard

    My only complaint or pain point is that I strictly want app wide state management. And from experience, I know that doesn't take wrapping all my screens and my app and everything in your library. It becomes a framework. I'd already built the entire app, just wanted to lace state mgmt
  • 0
    106d
    "Because junior devs suck when you let them "wing" it. Wall them through an opinionated structure to guarantee standard", agreed on this.

    This is why people use frameworks. And flutter itself is already a framework. Using another framework (getx) over a framework is nuts. A lot of what it does, can be done by official library: go_router, SnackBar(), setState(), shared_preferences, http, etc.

    I personally prefer to use what official flutter developer makes. That assures me that I won't have to made a huge change later.

    I can't help but to use riverpod since there is no easy way for synchronize the states of two distant widgets, the official way. One common use case for this, is shopping cart in e-commerce app.

    Riverpod used to be too convoluted / rocket science, I agree. But the most recent methods are pretty good and straightforward. The author himself seemed to have ditched the classic five types of Notifiers. Check out the latest documentation at https://riverpod.dev
  • 0
    106d
    @daniel-wu I haven't looked too deep into his reason for repeating existing functionality. If there's no noticeable improvement, that's redundancy. I don't know whether it applies to all other components of the project but at least, his go_router includes additional goodies like support for deep linking and stuff. Just skimmed through briefly

    The only features I liked about riverpod was:

    1) native support for the 3 states –loading, error, success
    2) I've forgotten what it's called but the part where cached data is displayed while fetching new one to display (stale while revalidate?)

    I never got to try out its actual reactiveness cuz the boredapi was down. But its syntax is crap(I need a linter ffs), dx sucks, docs too cumbersome
  • 0
    105d
    The official go_router package does support app links (android) and universal links (ios). I used them on my apps.

    Yes it has three states by default, it makes our life much easier when fetching online data. Also existing data can be shown while new data is still downloading. These can be implemented ourselves quite easily though, the only thing that I need from it is syncing states across many widgets. States are reactive, so I can't just replace it with database or shared preference, or backend API, or make some singleton classes.

    Personally I never have any issue with it's formatting, while coding on VS Code. You can make build_runner keep running in separate terminal.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment