Getting started with the Aurelia Store documentation

So I wanted to give you all a short update at where we are with the Aurelia Store Plugin.

I’m currently prepare the overall headlines for the future documentation of the Aurelia Store. Since the topic of state management takes some theory I want to make sure we have decent enough documentation to start with.

While in these first steps, I wan’t to make sure to get a high level bullet point list of topics. You can find the current state over at the Github Repository.

I’d appreciate help to get that list right. You’ll see sections, followed by few bullet points to indicate what each section is going to cover. Its important to state — heh — that I’m currently looking only for help on getting these headlines and bullet points right. After a few weeks I hope it to be in a good enough shape so that I can start with the initial set of documentation. Once the basis is there its much easier to look for help for specific sections.

So looking forward to all your inputs and lets create solid docs helping everybody to get on board as easy as possible with the new Plugin.

5 Likes

Looks good, minor question. When including as a dependency what does "main": false mean? How would you include it in a webpack build?

For webpack nothing specific besides npm/yarn Install is needed. The main false setting indicates not to load any file by default for the rjs build otherwise youd prebundle the complete rxjs lib which could be quite large. I’ll add those explanations as well to the docs.

3 Likes

Looks pretty complete to me.

I’m currently working on a new app and thinking about using aurelia store instead of redux… so when i read the docs and samples i was pretty curious why you choose rxjs… so i think its good that you put that topic on top.

Second thing i’m interested in was the difference to redux, which i used in my last aurelia app, especially in actions, why they are functions (redux-thunks) and not objects, why they are also the reducer, why do i need to register them… it would be nice to read somethin about it at the end of the docs.

I’m trying to map the redux approach to the aurelia store, but it takes some time to eg. refactor/rethink the pattern of “dispatching multiple actions in one thunk” and “multiple reducers listening to one action” to the “action/thunk/reducer-in-one approach” in aurelia store…

btw, appreciate your work on that plugin, also enjoyed your posts about hocs and redux!

Thanks for the Feedback. The later comparison section should briefly touch on the main differences to other Libraries, but it sounds like youd propose an in-detail comparison to Redux? The separation of actions, reducers and async monads (thunks, sagas, …) is a specific design descision from Redux. Thunks might be a bad comparison its more the way like redux-observable that fits aurelia-store.

Bottom line is im not sure how much should be part of the docs as it could easily turn into an infornation-overkill :wink:

I’ll make sure to address the high-level design descisions though like all-in-one vs split entities and the actual reason behind using rxjs

You’re right, after trying out aurelia-store last night, it was pretty simple to refactor and structure the code from redux to aurelia-store… i was just used to dispachting objects and mutating the state by several reducers that in the beginning it was to hard to see how i could achieve this with just dispatched reducers. I have to say at the end the whole thing looks much lighter than the redux code.

But there was one issue i came across i had to make some custom adjustments: in middleware i have no info about the current running action, nor the data/params. i hope it was ok to make an issue on github (its not an issue, more like a discussion for enhancement)

Great to hear that. I think being used to will be the hardest nut to crack with the documentation. As such, your inputs are very valuable thanks for them. I’ve pushed docs for the Why rxjs section, where I feel like most should be explained but I’m a bit unsure. Would appreciated feedback on that.

The resume is awesome, thats what the Plugin is looking for, a light weight approach, with respect to code you have to type, to state management.

With regards to the issue. Really every feedback is welcome, whether its a suggestion, or discussion or bug report. In this phase, before moving it to an official plugin, all questions are gold as they show what is yet unclear or could be made better.

Thanks for your time and effort, greatly appreciated

The docs are coming along. Slow but steady :wink: I’m about half-way done. Thanks to all issue contributors, together we’re shaping the Plugin for success. If you are reading this and still havent heard about the Store plugin hop over to the GitHub repo mentioned at the top, give it a try and report your findings.

1 Like