3 ms·

Is there an actual scenario for this? People either picks Angular/React/Vue and live within their respective ecosystem, why would they accommodate themselves wi

Is there an actual scenario for this? People either picks Angular/React/Vue and live within their respective ecosystem, why would they accommodate themselves with a solution that compatible to all of those but not as good as other state management store that tailored for one of them? I kinda missed the big picture here.

Octoth0rpe 7y ago
How about if you want to maintain your website in angular, but want to reuse your state management code with a mobile app written in react-native/weex?
- ehutch79 7y ago
  You'd honestly be better off rewriting it. And if that's a huge ask, you need to seriously reconsider what is 'global state' in your app. You state management shouldn't really have all your api calls in it. Especially if you're worried about cross platform, put your api interface code into a library, call that from components or your state management. If you find your state management code seems to exist only to call out to your api, it's probably not global state in the first place. Approximately 90% of the time, when people are posting questions about VueX, my first thought, is 'that really doesn't seem like global state'
  - williamdclt 7y ago
    I don't think I get it, what do you use global state for? And what do you use to query your API and store responses then? Most of the time yeah I do use Redux (sagas) to query my API and store the result. Many of my components need access to the same data (who's the current user, what's their list of items, what's the current item being looked at...), so it's at least shared state if not global
    - ehutch79 7y ago
      It's super dependant on the app. however, abstracting your api calls to a single library is helpful for any app beyond the most simple todo app. Things like the current user are 100% global state. A list of user settings, or valid values for a dropdown that doesn't change often (like a list of timezones, or countries), totally global state. A list of objects only shown on one page or in one component? That component can call an api library for the data itself. State of a component? Definitely not global scope. Specific example; virtual scroll for a table. storing the offset as global scope. As soon as a second instance of the component was loaded on the same page there would be major issues. Data that gets paginated should probably not be in global state, or cached heavily, depending on the app. A couple dozen entries is fine, but the idea of pulling every record in a list from say, an erp app, and then paginating in memory, would wreak havoc on a user's browser. And you're keeping that in the browsers session memory. Not to mention ramifications on the backend, even if it is cached. and then you need to deal with cache invalidation, and then...
- mythz 7y ago
  It doesn't let you write generic components that you can use across all fx's, it just lets you use the same limited state API to set state in different fx's. Most of the effort with porting code amongst different fx's is refitting your logic into their different component models. So instead of using the well-tested, documented, native reactive model in each FX, yo'd be limiting yourself into using a limited, non-standard state wrapper API. I don't see any value in this abstraction myself. Forcing myself to use it would generate more abstraction/boilerplate in refactoring out custom logic so it's not tied to any FX. If you want to write code that targets multiple JS fx's you're better off with a well thought out proper solution that lets you develop components that you can use in all major components like https://stenciljs.com https://stenciljs.com or alt solution that lets you target Web Components.
- xxxpupugo 7y ago
  This is a weird choice of technical stacks, TBH. You never-the-less need to maintain two different frameworks, the UI component will be hard to look consistent, and build/testing flows are probably different, and I have my reservation how much code can be actually shared, and to share that code what the cost you are paying. Better just use React all the way.

Octoth0rpe 7y ago

How about if you want to maintain your website in angular, but want to reuse your state management code with a mobile app written in react-native/weex?

ehutch79 7y ago
You'd honestly be better off rewriting it. And if that's a huge ask, you need to seriously reconsider what is 'global state' in your app. You state management shouldn't really have all your api calls in it. Especially if you're worried about cross platform, put your api interface code into a library, call that from components or your state management. If you find your state management code seems to exist only to call out to your api, it's probably not global state in the first place. Approximately 90% of the time, when people are posting questions about VueX, my first thought, is 'that really doesn't seem like global state'
- williamdclt 7y ago
  I don't think I get it, what do you use global state for? And what do you use to query your API and store responses then? Most of the time yeah I do use Redux (sagas) to query my API and store the result. Many of my components need access to the same data (who's the current user, what's their list of items, what's the current item being looked at...), so it's at least shared state if not global
  - ehutch79 7y ago
    It's super dependant on the app. however, abstracting your api calls to a single library is helpful for any app beyond the most simple todo app. Things like the current user are 100% global state. A list of user settings, or valid values for a dropdown that doesn't change often (like a list of timezones, or countries), totally global state. A list of objects only shown on one page or in one component? That component can call an api library for the data itself. State of a component? Definitely not global scope. Specific example; virtual scroll for a table. storing the offset as global scope. As soon as a second instance of the component was loaded on the same page there would be major issues. Data that gets paginated should probably not be in global state, or cached heavily, depending on the app. A couple dozen entries is fine, but the idea of pulling every record in a list from say, an erp app, and then paginating in memory, would wreak havoc on a user's browser. And you're keeping that in the browsers session memory. Not to mention ramifications on the backend, even if it is cached. and then you need to deal with cache invalidation, and then...
mythz 7y ago
It doesn't let you write generic components that you can use across all fx's, it just lets you use the same limited state API to set state in different fx's. Most of the effort with porting code amongst different fx's is refitting your logic into their different component models. So instead of using the well-tested, documented, native reactive model in each FX, yo'd be limiting yourself into using a limited, non-standard state wrapper API. I don't see any value in this abstraction myself. Forcing myself to use it would generate more abstraction/boilerplate in refactoring out custom logic so it's not tied to any FX. If you want to write code that targets multiple JS fx's you're better off with a well thought out proper solution that lets you develop components that you can use in all major components like https://stenciljs.com https://stenciljs.com or alt solution that lets you target Web Components.
xxxpupugo 7y ago
This is a weird choice of technical stacks, TBH. You never-the-less need to maintain two different frameworks, the UI component will be hard to look consistent, and build/testing flows are probably different, and I have my reservation how much code can be actually shared, and to share that code what the cost you are paying. Better just use React all the way.