You bring up a great point. You really shouldn’t use context except for special use cases. Typically it’s reserved for libraries like redux, mobx, apollo, etc… or anything that has a <Provider>. In this case I was essentially making my own micro library to hold a little bit of global state. As stated this was just for a few things that can’t easily be passed down, like a dropdown modal banner. You don’t want to pass that down 20-30 times down through each component. Every component would have to have knowledge of this modal prop for it to work which is not ideal.
Also worth repeating I haven’t tried this in prod. so there may be significant flaws in it (currently using Redux for that same global state).
I also agree that in general the spread operator is an anti pattern. Ideally you should clearly mark every component with a prop instead of {...this.props} but it comes with a cost. If it stops me from decomposing my component into smaller chunks i’ll pass down with the spread. Also typically i’m only using this in an “area” of the UI like say a comment, and then the comment might have 8 smaller components and in this area I may use it. I would never use the spread from say the root chat page, down through lots of components where it’s very difficult to tell where it’s coming from.
My general rule is to try and pass it down explicitly but if there is a lot sometimes I will pass it down several layers with ...this.props and also typically will omit un-needed ones. Then, most importantly the child view or container container needs to specify propTypes so that if something above changes you’re notified in dev when it breaks. It also has a cost of not being explicit (I think that’s the main rub).
Well spread operator works if you consider higher order components where you have no clue what is being passed to the wrapped component. You are just making some changes to behavior but passing the data as it is or slightly modified.
Let say a component may take more than 5 props and the form have 10+ such components why would I write every prop by hand instead of spread operator?
Defining things as anti-pattern is all fine and dandy but there are specific cases where spread operator is a better suited. Similar things have been said in Java community or .NET community regarding ServiceLocator pattern but it is used heavily by many frameworks and there is a use for it.
This has gone severely off topic - I’ve also contributed. Let’s go back to the original discussion, and if we want to keep talking about spread operators we can start a new thread.
is there (or is there going to be) a repo supplied by MDG that shows what an example app would like like with meteor 1.5 with a full apollo/redux implementation? i think that would help visualize a lot of how to setup things.
off from apollo, it might just help to have a bulleted list of all that is in 1.5. i’m still not quite sure what is coming besides a faster build process
I was having a conversation with a coworker and trying to explain advantages of Apollo and give some examples, and how it simplifies and lessens the need for redux, but I was having hard time thinking of good, concrete examples. Could you share any sample code of this point above? Or just describe any common examples? Particularly I’m trying to come up with good examples that use Apollo for local operations and state.
This is very helpful, as other stuff you’ve posted, thanks. It would be great to have two versions of an app (like a todo or something) to compare traditional REST+Redux vs Apollo.
I have a screencast coming up migrating this older Meteor React app: https://github.com/AdamBrodzinski/react-ive-meteor , though it doesn’t have Redux, it’ll be using the container pattern to separate data handling.
Yeah so while the Blaze discussion is obviously important, I’m still really interested in what we can expect with regards to React + Meteor + Apollo integration in 1.5, as that’s probably where a large number of users are going to attack this from.
What are we likely to see to make integration with Meteor easier? Anything? Because currently I feel like while the data-loading is beautiful and easy… Mutations, Optimistic UI, subscriptions, etc are all way, way, waaaaay harder to do than in Meteor with minimongo, etc.
