Still alive?

[AnthonyLamot]

Hi there!

This is exactly the kind of project I've been looking for!

However I was a bit disappointed to see that Accounts is still on the TO DO, and that the last update was a year ago. Is this project still alive?

If anyone knows other good Meteor-React-Redux resources, I'd be happy to learn!

[nqbao]

I don't have time to actively maintain this anymore. So the accounts part was never got done. You can try to fork the project and integrate with accounts.

[AnthonyLamot]

Thank you for the quick reply. I'm considering doing just that!

However I would really appreciate your opinion on something...

As I'm wrapping my head better around Meteor-React-Redux I've become aware of two issues (not necessarily related to Accounts, but which could also relate to the Widgets example). These issues arise when you let all data (including Collections) flow through the Redux Store:

1. You loose out on Meteor reactivity (with vanilla Meteor, when the MongoDB updates, the data shown in the View also updates). Solution: We could write additional Redux actions & reducers on the server-side.
2. You loose out on Meteor optimistic UI (with vanilla Meteor, when you would add a new Widget, the client will already try to predict what it should look like even before the server responds). In the example here, while calling a Redux action (e.g. to add a Widget), we essentially wait for the Meteor method to insert the Widget in the collection before moving onto the Reducer which will update the Redux Store, who's State in turn updates our View. (Of course, all of this happens so quickly that you wouldn't notice it, but you might notice it if you were running it on a slow server or when you'd have a mobile application). Solution: We could write additional logic in the actions that update the Store immediately with the new Widget, and if it turns out we weren't authorized to call the Meteor method, we can still use, within the Action, the .catch of the Promise to adjust the Store (removing the Widget we already added).

So basically, by introducing Redux into our Meteor-React solution, we're missing out on two great features of Meteor. Both of them can be rebuilt using self-written logic, but it frankly seems a shame to do so.

I was wondering if you (or anyone else reading along) has considered these things and what a solution - that maintains these Meteor features but still leverages Redux - would look like?

[FBosler]

Hi Anthony,

so I stumbled across this admittedly a bit dated post chain. I think it's still quite interesting.

https://forums.meteor.com/t/using-redux-with-meteor/15649

I asked Adam (https://github.com/AdamBrodzinski) the following:

Now I have been thinking about including Redux also (because it seems important to understand Redux and this is also very much for me to learn all the important technologies). It seems that you have quite a good handle on how to use Redux in a Meteor context, which is why I was hoping you could help with this SO Question: https://stackoverflow.com/questions/44789758/how-to-avoid-bloated-store-when-using-redux-in-meteor-app1

to which he replied:

I've been down that rabbit hole and have concluded that the best way to use Redux with Meteor is to only use it for global local state (not saved to the DB).

I've moved away completely from Subscriptions and have used Meteor methods instead. In this case you can make a 'container' component the wraps the view and this container component has the meteor method calls and handles the result data or error and passes that down to the view.

Ideally i've ditched Meteor all together but I wouldn't recommend that to everyone.

Maybe this does help a bit?

[nqbao]

Thanks @FBosler for your answer. This is also true for my case. Eventually, I only use Meteor methods for my projects and avoid using Meteor collection. There is also performance impact because the data is duplicated two places: the redux store and mini mongo. So I would recommend the same thing ditch Meteor all together

[AnthonyLamot]

@FBosler thanks a lot for that post and as you probably noticed I found my way to your SO post. ;-)

The thread from the Meteor forums is definitely interesting, although it actually doesn't address the question you asked! Although someone implied it's actually not an issue to fill up the Store with collection data.

@FBosler @nqbao do I get it right that for a Meteor-React-Redux stack:

1. you don't use Meteor subscribe / publish (I am asking it explicitly since Redux also has a subscribe() 😁 )?
2. you use event handlers, which > call actions, which > call A) meteor methods to make updates to the collections, and, given that these give a positive response through a promise B) call reducers to update the Store?
3. you use Redux' mapStateToProps() to finally get the data into the View (i.e. React Component)?
4. in step 2) you alter the promise so that you can have optimistic UI (e.g. by adding a toDo to the store, but if the Meteor method returns an error, you remove it again)?
   5; you add additional listeners that check if there's been a change on the server side, so that the Store gets updated as well (which in turn updates the View)?

Finally @nqbao, seems like you got fed up with Meteor and replaced it. What do you use for your backend these days? 😄