
XSM: State management for Angular, React, and Vue - feross
https://github.com/peterluhub/xsm
======
psychometry
Every new OSS repo's README should convince me to try it instead of the
current standard tools, or at least compare it to them. In my case, I'd want
to know what makes it better than Vuex.

~~~
peterluhub
It does have the key points listed in the readme. It probably is so obvious.
Let me summarize them here. 1\. Simplicity - The concepts of XSM are
straightforward and easy to grasp. Whereas, the concepts of Vuex are not as
easy to understand. 2\. Vuex is for Vue only. On the other hand, XSM works
Angular, React, and Vue. Learn once and be good with the 3 frameworks. Chance
of code reuse with XSM.

------
ianstormtaylor
When I see things like this:

    
    
        setcfg({'framework': 'React'})
    

I immediately think to myself that the designer of the API either (a) values
tiny function names over understandable ones, or (b) hasn't given naming
enough thought to be consistent. Either way, it's not a good sign and turns me
off from investigating further.

~~~
whichdan
[https://github.com/peterluhub/xsm/blob/master/xsm.js](https://github.com/peterluhub/xsm/blob/master/xsm.js)

The package only exposes 9 functions, and the naming is mostly consistent.
There's no benefit to publicly nitpicking function names in something with
such a small API.

~~~
rat9988
Honestly, no need to put much thought in gp's comment. He just wants to show
off that he is an experienced engineer that values good code and readability.

Edit: for those who disagree and downvote. Not only gp's comment doesn't
adress the core issue and is a direct attack to the developer, but it cannot
even be accepted as valid and helpful criticism. His point b says that it is
possible that the developer doesn't value consistency, while his point a says
he might be consistent with short naming. These remarks make it look more like
random possible remark than ones that are really specific about this project.

------
ng12
You could implement this in a dozen lines of code using React.Context. What's
the benefit for React specifically?

------
peterluhub
I have published a github repo that contains the real apps to show how to use
XSM to manage app state and handle the API logic to the backend.

[https://github.com/peterluhub/realworld-
example](https://github.com/peterluhub/realworld-example)

It implements the Realworld Example App specs. The state and API logic are
factored out into an NPM package(rw-xsm-handlers). The intention is to use the
same code(state management and API) for all the XSM supported frameworks to
implement the Realworld Example App specs.

The React example is finished. Angular and Vue will be added later.

------
xxxpupugo
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
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
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
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
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...

------
heracek
From React developer perspective this looks ugly (at least for now). It is
dependant on class-based components, it will do nasty modifications to your
class instances.

You can do much cleaner job using React hooks.

------
keb_
The fact that it only works with Angular, React, or Vue is a little
discouraging (or at least, that's the impression I get by the `frameworkValue`
config). Was initially excited to check out a new general-purpose state
management solution.

------
rafaelgarrido
Would that work with lazy modules in Angular?

------
ivankolev
Not affiliated, I just want to throw in Akita
[https://github.com/datorama/akita](https://github.com/datorama/akita) from
datorama, in the conversation, I have successfully used it in an Angular
project, but it's framework agnostic, built on top of rxjs.

------
digianarchist
This project is a month old and maintained by a single contributor. Tread
carefully.

------
germs12
I already have this merged into a feature branch.

------
stingraycharles
Request for mods: Title of post currently lacks “for Angular, React, and Vue”
which makes it confusing.

~~~
dang
Ok, we added those.

------
fabiofzero
Looks better than Redux, but then again what doesn't?

~~~
aarpmcgee
I still don't quite understand the reasons for the amount of shit Redux gets
these days–I find the code (especially when using Redux Starter Kit w/
Typescript) to be easy to debug, easy to read, and easy to maintain. To me,
the boilerplate is evidence of a degree of abstraction that may not always be
appropriate for every SPA, but in my experience, is still often a really
useful and practical choice.

~~~
root_axis
Redux adds more complexity and is simply unnecessarily. You just don't need
it. If your back-end is something like a wire protocol over ws where you've
already structured everything as "actions" or "messages" it's a decent fit,
but even then React hooks are a better choice (e.g. reducer hook). For
everything else there's just no reason to use it. I would go so far as to say
that use of redux is an anti-pattern.

Of course, if your app is already built on redux, that doesn't mean
refactoring away from it should be a business priority, but new projects
should avoid it.

~~~
ng12
> You just don't need it

I have a lots data that needs to be globally available between multiple pages
and is largely interdependent (i.e. one update might affect multiple slices of
the data). The data needs to be updated optimistically (i.e. we show updates
to the user before the fetch succeeds and unwind if it fails) and the updates
are triggered through a mix of web socket polling and user actions.

You're right that I don't _need_ Redux for this project, but oh boy I really
like using it.

~~~
root_axis
> _lots data that needs to be globally available between multiple pages and is
> largely interdependent_

This is the ideal use case for react context. It's not as if redux is doing
something magical to achieve that result, it uses context under the hood
anyway, but it adds on the complex and usually unnecessary action/reducer
abstractions. I have mentored about two dozen developers on react and redux
projects over the past three or so years, I've learned this lesson the hard
way.

> _the data needs to be updated optimistically (i.e. we show updates to the
> user before the fetch succeeds and unwind if it fails) and the updates are
> triggered through a mix of web socket polling and user actions._

Redux doesn't address these problems specifically, but I'd be curious to
understand why you think redux is of particular value for them.

> _You 're right that I don't need Redux for this project, but oh boy I really
> like using it._

Well that's fine, I'm not arguing that you shouldn't use what you like.

~~~
ng12
> This is the ideal use case for react context.

Not really. React.Context solves the global availability bit but it does not
scale with the size and complexity of your data. You'll end up building a
custom Redux store inside your Context anyways, except now with an uglier API
and no devtools.

Alternatively, you could just use a bunch of independent React Contexts, but
that becomes unmanageable quickly especially if the Contexts are
interdependent.

> Redux doesn't address these problems specifically, but I'd be curious to
> understand why you think redux is of particular value for them.

The action/reducer model is a very natural way of modeling it. The business
logic and data fetching layer is completely disjoint from the actual data
store. We can simply describe what happened -- hey, we tried to post this
data, this request succeeded, but this one failed and here's the error message
-- and then let the reducers decide how that updates their state, if at all.
It makes it much easier to refactor code and add new features, especially when
they can just hook into existing actions.

Even if I didn't use Redux -- and to be honest I don't _love_ the API
sometimes -- I would follow the Redux patterns. When done well it's a really
seamless way of managing data that would otherwise be a lot of ugly business
logic spaghetti.

> have mentored about two dozen developers on react and redux projects over
> the past three or so years, I've learned this lesson the hard way.

If you're mentoring novice developers I don't doubt the apps they were working
on didn't necessitate Redux. It's a powerful tool but it comes as a price,
which is why as much as I like it I avoid recommending it to people
(especially junior developers) unless they have a really good case for it.

