Roadmap for Alt

[ttsirkia]

I'm starting a project to convert some old Knockout.js things to React and currently looking for a nice Flux library.

Redux contains some annoyances and therefore Alt looks quite promising alternative. For example, I'm not a fan of big switch statements, actions as objects etc. In my opinion, Alt manages these much better.

But I'm bit worried that is Alt still maintained? It seems that this repository has been quite silent lately. Is there some kind of roadmap for the library? It would be a pity to choose a Flux implementation which is not actively maintained anymore. Reflux is another alternative but it is ES5 and the maintenance has practically stopped.

[moliver-bb]

I second this! I love the library and have already implemented it in a couple of projects so would be great to have a road map for the future!

[goatslacker]

Hey, thanks for your concern. I'm still maintaining it but I'm not sure what to do or where to take it at the moment since I'm not actively using it. I'll have some free time coming up where I can dedicate to open source and be a responsible maintainer. In the meantime, I'm open to suggestions, maintainers, comments, whatever.

Disclaimer: a lot of the companies that were using Alt in production are either thinking of or have switched over to redux, so in the future I'll be maintaining Alt mostly as an alternative to redux.

[ttsirkia]

Nice to hear! Yes, Redux is of course the most used library but as I mentioned, in my opinion Alt does many things in a way that is more suitable for me.

[goatslacker]

@ttsirkia I'd love to hear your thoughts on why you feel it's more suitable for you and what you like/dislike about it.

[ttsirkia]

I have to say that I'm not totally familiar with Redux but as having read documentation a lot (both Alt and Redux), these are my opinions why I prefer Alt:

• In Alt, state is mutable. In Redux, constructing a new state after each action is quite frustrating and requires more code.
• In Alt, actions are functions and defining actions is trivial. Actions are launched by calling the functions. In Redux, you have to remember string names of the actions and construct an object that describes the action. There are ways to reduce the boilerplate but Alt does this with less code straight away.
• In Alt, binding actions to stores is very easy. I like the way that implementing function onFoo those actions are handled there just by stating that these are the actions that are available without explicit binding between the actions and functions (bindActions). In Redux, you will end up with a massive switch statement or use something else to reduce the boilerplate. But again, using Alt is much easier.

Someone may argue that Redux is better in other things but this is the impression that I currently have after doing some small experiments.

[goatslacker]

So if there was an Alt with a redux backend then that would be 👍 ?

[taion]

That would be all sorts of amazing. Re-build Flux with mutable stores/&c. on top of Redux?

Is the core of this essentially a competing model to redux-thunk/redux-saga for handling side effects?

[goatslacker]

Alt was always supposed to be Flux + tooling so this would instead be Redux + tooling.

[taion]

I haven't tried, but it seems like getting something like data sources to work in a Redux paradigm would be tricky – or at least very different.

[ttsirkia]

@goatslacker I don't see any reason why there should be Alt with Redux backend. Alt and Redux both do the same job with different approaches and if Alt does that better (at least with one's personal opinion), I don't see any reason why to use Redux at all. If there are multiple Flux libraries available, each developer can choose which of them suites best.

[drinchev]

There are a couple of points in a reddit thread :

https://www.reddit.com/r/reactjs/comments/3u54ju/why_has_redux_become_so_popular_vs_altjs_and/

One of the things mentioned there is :

Quality of documentation > quality of technical features

To be honest I didn't know about Alt until I recently had to help a React team, which was using it. IMHO It feels better than Redux and far more guiding about how to structure your app.

Redux needs too much thinking about your data structure in the very beginning. Also actions are a bit more difficult to make ( IMHO ).

[djbobbydrake]

Just wanted to say that we have been using alt for a year in production and would love to see it continue to be maintained. It has very much propped up our little startup, so also thank you for all your hard work.

[goatslacker]

Yeah I've got some plans for it. I plan to put some code up some time soon when I get all the tests passing. My goal is 1.0 (stability) and super attractive documentation.

I plan to get there by removing a lot of things (cruft? confusing idioms? multiple ways of doing things?) to bring down the size (to ~2kb when min+gzip) but still keeping the features that people love and frequently use.

[taion]

Commenting from the sidelines a bit, but having like 3 or 4 different ways to do everything really was the weirdest part of the Alt API.

[avdeveloper]

piggybacking on @taion, I feel like the API for the AltContainer lets you take different routes to get to the same destination (ie. choosing between transform, inject, or render to pass props data to the dumb component). I can't totally say it's a bad thing because I do find scenarios to use each one, but then I could just be using it improperly.

[goatslacker]

If you want to track progress or check out what the code is like you can see https://github.com/goatslacker/alt/pull/669

Please also voice any concerns there.

[ryanzec]

@goatslacker So you said:

I'm still maintaining it but I'm not sure what to do or where to take it at the moment since I'm not actively using it

Out of curiousty, is this because you are no longer doing work that needs a state management library or because you are using something else?

[ziflex]

@goatslacker why are people switching over to Redux? Because of trend? I have very bad experience with Redux and still don't understand why people love it so much.

[icoloma]

There is a lot of people that would prefer to work on alt than redux, me included. I was following #669 and it seems that documentation is a big issue, so I rewrote the documentation for the current status of 1.0 (according to what I could see in code and tests).

I put the doc in a separate repo and created a preview here. TL;DR the new way of managing Promises is brilliant and exactly what I was looking for.

If possible I would like to volunteer some extra time to integrate this with the documentation (should separate 0.x documentation to keep it online) and publish 1.0-alpha on npm. I can also clean some issues that do not apply to 1.0 now (source does not exist anymore etc). But for this we need @goatslacker assigning some extra maintainers.

[acroyear]

I and my office (one small division but of a VERY large company that I'm not allowed to name) looked at alt and redux and also definitely preferred alt for its simplicity and lack of constant boilerplate. The fact that there were so many more questions out there on getting redux to work at all actually was, to us, a clue that its popularity was not necessarily something to associate with its ability to help make projects successful.

We've certainly been pushing the edge a little bit (like having actions that return promises, and stores that have to maintain that searching for 'x' is already active so don't fire a second search and just receive the promise from the first one), but it has been absolutely solid for us.

I'm definitely of the experience that lack of updates (provided there's not a thousand bug reports) is not lack of stability or quality. I've got code in Java I wrote 20 years ago (using Java 2D and transforms) that is still out there, in production, unchanged since the day I wrote it.

[snags88]

this is somewhat related to the alt library, but wanted to throw it on here to get some visibility and get the word out.

We use Alt.js as our flux implementation on our team and I developed this library called alt-reform out of necessity to have a more opinionated way of creating forms in Alt. Redux has Redux forms so I figured why not open source this library. Anyways, our team has been using this to develop forms more consistently and efficiently, but i'm sure it's missing some features.

On a side note, if @goatslacker is looking for extra maintainers, I would like to throw my name in the pile along with @icoloma among others

[icoloma]

After trying to contact with @goatslacker unsuccessfully, the Koliseo team have decided to fork the project. Caution though: as part of the fork process, there are a couple of changes that have been included:

• Synchronous, async (Promise-based) and generated actions are created from a single createActions method.
• We have dropped the Store lifecycle events, as we don't see a clear reason for those. We keep the action dispatcher (now moved to its own class) and Store change events.
• We dropped Store saving and restoring. It seems that this can now be done easily without involving alt at all, we will probably add a doc page explaining how to do this.
• The behavior for Promises is slightly different, as they are now being returned from Actions for much easier testing in applications.
• AltContainer now injects the state from the Stores directly as properties, merging if there is more than one store specified.

This is early stage, so any feedback is welcome. An example application is in the works.

[philstrong]

We've converted completely off Alt onto Mobx https://github.com/mobxjs/mobx This affords us ease of testing (Mobx is a utility, not a framework) Multiple instances of the same store (again not a framework just objects) Removes silly boilerplate (e.g. Actions) Not flux but is reactive Mobx has a concept of actions which are just functions marked as such. If you alter the state outside of an action it cries at you. We continue to create 'Stores' which are really just Classes Vastly improves page load times because re-renders are heavily reduced Very large data sets we handle with shallow references observable.ref