Still active

[adambrodzinski]

Still active

[AdamBrodzinski]

Yep, I try to put in as much time as I can but it's been pretty hectic lately 😃 Some time I would like to convert reac-tive-meteor repo to use flux (or a branch).

The most recent is the redux branch. I would recommend starting with that first if you're just starting out with flux. If you do make sure to breeze through the first part of the redux docs as it explains it at a lower level.

I'm planning on migrating all of my apps to Redux soon... the dev tools are great, it has a simpler concept, and easier to consume with React. Alt is my second favorite... both play well with Meteor!

[brandonmikeska]

Awesome! Thanks I really appreciate it. Planning on migrating a medium sized Rails app and want to do some research before jumping in.

[AdamBrodzinski]

Awesome! Yea def. checkout these to help you decide which one works best for you:

Alt:
http://alt.js.org/guide/

Redux:
https://www.youtube.com/watch?v=xsSnOQynTHs
http://rackt.github.io/redux/

And the glue that makes it easy to use collections with Redux/flux (used in this repo):
https://github.com/AdamBrodzinski/meteor-flux-helpers

[brandonmikeska]

Reading through these, do you advise such architectures from the beginning or do you move to these once you realize you will need them?

My brain is trying to grasp all the complexities and I am just wondering if it makes more sense when you need to do this, versus doing them just in case you might need to do it. If that makes sense...

[AdamBrodzinski]

So when I made my first React Native app I ran into this. I went with the basic, have the parent pass down data to the children approach. This worked for a bit but then I needed to suddenly prime that state from another component. I then either needed to push that state higher up the tree or use flux to create a 'global' state for others to consume.

If you're app is going to be larger than a leaderboard or todo example app, I would go with the extra work of learning Redux. It seems more complex but once you learn the concepts it will make your app more maintainable, (much) easier to reason about when debugging, etc...

Doing it the non flux way works but it gets messy when you're pushing down into props more than 3 levels deep. After that it's hard to tell where a prop originated from. It's also very hard to move the component without breaking something because it assumes those props will be threaded through.

With Reflux you solve the threading problem by using connect to slice off and watch a part of the single state tree and then it passes this state into a components props. you typically only push it down to 1-2 components, making it easy to track/change.

Decoupling logic outside of the view is also helpful and Redux/flux helps you do this. Though you don't have to use flux to do this of course.

The http://react-ive.meteor.com/feed repo has an example of using the meteor mixin to sideload collection data and also decouples the view by putting stuff into a 'domain' object.

This method (meteor mixin) works but I find it to be less efficient. It's prob. the easiest to use if you're familiar with the 'meteor way' of doing things.

Redux is def. easier than learning CSS but it's one of those things that looks really complex until you understand it. Basically you're doing this in the lifecycle:

• single state tree starts out empty/initialized {userColors: ['blue'], foo: 1, bar}
• view passes an object with meta data to dispatch({favColor: 'red'})
• dispatch passes it to 'reducers' which use a switch to determine if they're interested in that meta-data, if so the reducer returns a new piece of state representing what the new state should look like using meta-data to change it: return {userColor: ['blue', 'red']}
• once reducer returns Redux checks with === to see the returned value is different than the old one, if so it fires a changed event. In the docs this just console.logs. If you're using react-redux then it also lets you use a connect function that wraps a component and passes down redux state as props. Then your component just uses this.props.userColors to access the data. It also lets you only watch a few keys of the tree so it's more efficient .

One last catch is using multiple reducers. Because having one reducer with one switch statement can be quite large, it allows you to have multiple reducers that only focus on one thing, and then it uses all of them in the order they're passed in.

Hope this helps!

[brandonmikeska]

Really appreciate it! Any chance you have an example with some sort of router?

[AdamBrodzinski]

Not with flux, but the reactive-meteor has one.

I do have this snippet to get FlowRouter to work with redux though.... :

FlowRouter.route('/about', {
  action: function(params, queryParams) {

    ReactLayout.render(MainLayout, {
      content: <About store={store} />
    })

  }
});

https://forums.meteor.com/t/flux-example-app-with-react-meteor/7416/41

This is used instead of the provider in the redxu-react docs. If you use react-router then it works just like in the guides.

[brandonmikeska]

Yeah I meant with redux! The docs are making more sensing after reading through them a couple of times. 

—
Sent from Mailbox

On Wed, Sep 2, 2015 at 1:05 PM, Adam Brodzinski [email protected]
wrote:

Not with flux, but the reactive-meteor has one.
I do have this snippet to get FlowRouter to work with redux though.... :

---

Reply to this email directly or view it on GitHub:
#7 (comment)

[AdamBrodzinski]

Oh yea actually the above is with redux too lol. Yea for me actually doing to first part of the guide in the console made it 'click', it's a bit much if not. I also hit submit before pasting the code block, edited is above.

[brandonmikeska]

Awesome. I'm excited to try this out tonight. Thanks with all the help!

—
Sent from Mailbox

On Wed, Sep 2, 2015 at 1:08 PM, Adam Brodzinski [email protected]
wrote:

Oh yea actually the above is with redux too lol. Yea for me actually doing to first part of the guide in the console made it 'click', it's a bit much if not.

Reply to this email directly or view it on GitHub:
#7 (comment)

[brandonmikeska]

So why did you change from Alt to reflux?

[AdamBrodzinski]

I assume you mean Redux (though I have used that too). I have Alt in two projects currently and am migrating away from it because:

• Redux has a single tree of state as opposed to multiple 'stores' that all have their own state. This is easier to reason about at scale.
• Redux has less boilerplate to hook up to a React view (especially with multiple stores/reducers).
• Redux has less going on with 'action creators' as they are regular functions that just return an object (you could even skip them and dispatch this directly in the view). Side effects like AJAX or Meteor inserts/updates can go here easily.
• Alt's chrome tools are buggy and sometime don't show up
• Redux's dev tools are really nice and are just getting started
• A hot load (not hot _re_load) with Redux retains state

That being said, Alt is my favorite out of the Flux bunch. Redux is tech. not flux but the same concept.

[brandonmikeska]

Thank you. I owe you a drink or food if I am ever in your area!

[AdamBrodzinski]

Haha no prob, glad to help! 🍻