is there a way to wrap the npm modules like in the material-ui-leaderboard to a package, such that those modules can accessed within the same package or other packages?
Yes, read the documentation for âcosmos:browserifyâ
@sashko Am I missing something or is there not really an easy way to import CSS from a React Package?
Random (and possibly silly) question:
Why is Meteor data accessed thru this.data
instead of this.state
? Just curious.
Gerard
Hi guys! I have a preview of the new official React and Meteor tutorial here: Request for feedback about new official React tutorial
Please check it out and leave comments!
This is covered partially in the guide: http://react-in-meteor.readthedocs.org/en/latest/meteor-data/#design-notes
did you get past this? Iâm getting the same problem
This is currently a known bug: https://github.com/meteor/react-packages/issues/39
We are working on fixing it ASAP.
First, I think this is awesome and really appreciate the work to provide first-class support for React for the view layer. But I share the concerns mentioned here.
I havenât seen this addressed yet. I have more experience with React than with meteor, and I think introducing this new concept of this.data
is very un-react-like. Components should be composed of props and state. In our own non-meteor flux implementations, we typically attach fetched data to state in the component.
Sometimes weâll use the component as simply a data fetcher, but in this case the data still gets assigned to this.state
, and then passed into a child component as a prop. I havenât yet dug into the mixin code to see if there is a reason this is necessary (will try to do so), but offhand I donât see why we couldnât be using getInitialState
and this.state
for the reactive meteor data. As mentioned it means we cannot use shouldComponentUpdate
as intended, nor can we use pureRenderMixin
. And I think in general it adds significant complexity to the React side of the equation.
Pete Hunt also uses this.data
for his Minimongo cache implementation. Iâm curious why as well but it might be because it gives them more control over when it will render? example:
[quote="rralian, post:50, topic:6150"] As mentioned it means we cannot use shouldComponentUpdate as intended, nor can we use pureRenderMixin. And I think in general it adds significant complexity to the React side of the equation. [/quote]
You can still use the Meteor mixin in a âcontainerâ component and then pass the data to the child. For example the âFeedListContainerâ component would fetch data and render FeedList
while passing this.data
as itâs props. This also makes FeedList
more re-useable.
You can still use the Meteor mixin in a âcontainerâ component and then pass the data to the child.
Yep, I recognize that. My point is that the container component in most flux implementations still generally uses setState
as the mechanism to trigger a re-render (upon observing changes from a store). That is at least how I am used to working in React. And Iâm not sure why we wouldnât use the same general approach here, particularly as it seems more in line with how React is meant to work.
Pete Hunt also uses this.data for his Minimongo cache implementation. Iâm curious why as well but it might be because it gives them more control over when it will render? example:
https://github.com/petehunt/minimongo-cache#working-with-react
Fair enough, I hadnât seen that before, but I would suspect youâre correct about the reasoning. Maybe we have a similar reasoning for using this.data
in this meteor-react mixin, but Iâm not yet understanding it.
Facebook Parse also uses this.data
, FWIW.
IMO it doesnât make sense to use state because if you want the data you are loading to be able to take state as an input, you end up with a circular dependency on state itself, and a potentially infinite loop of loading new data.
I think that using transient state (regular array) with an event emitter and observing a live data stream are going to be fundamentally different. Also the circular dep that Sashko mentioned makes sense.
Disclaimer: Iâm writing this without having written a single line of React.
This, from what I can tell, is merely an implementation limitation that you are talking about. Or we could frame it as a UX issue like: Meteor/React should be able to âjust do the right thingâ with this.state
, i.e. differentiate itself what parts of the state come from the regular React side of things and what properties I have (in the previous autorun cycles) added on in my Meteor-related code, and so there should never be a circular dependency issue that prevents the ideal UX in the first place.
(EDIT: Implementation-wise it seems to me no trouble to remember what parts of state came/come from where and as such not pass âMeteor-sideâ parts (what is in this.data
now) back into the function/method that is supposed to create them, not consume them.)
I might be missing something here, but wanted to share this, just in case I donât. Because even without having any practical experience with React itâs clear that âexcellent UXâ and âkeep deviations from well-known workflows as minimal as possibleâ (especially for âexternalâ tools like React; and this basically also ties in with ideal dev UX) is a big part of what Meteor is all about and (most) anything that brings us closer to those ideals is a good thing.
I might be wrong but my impression is that state should be reserved for keeping track of the state of your UI while data is simply data. Not sure why youâd couple the two together? Then again, Iâve never done React outside of the basic tutorials.
I think thatâs exactly what we are doing, by following the trends in future React development for the observe
API, and popular packages like Parse. Also, AFAIK people who use Flux definitely donât put their server-side data on this.state
.
Okay. Got it now.
try to put this on the guide as well.
Itâs worth mentioning it there.
@dgreensp we should write something up about this since people keep bringing it up.
Probably right next to this section: http://react-in-meteor.readthedocs.org/en/latest/meteor-data/#why-we-decided-to-ship-a-mixin
Call for community React related packages to put in guide
Hi everyone who has been posting in this thread! I want to compile a list of useful React+Meteor projects that have popped up since the initial release of these packages, and add them to the guide so that people donât have to read all of the github issues to find this stuff.
Iâm going to go through the conversations on GitHub looking for those projects, but if you have others that I should mention, let me know!
While youâre planning what to include in the docs, could you consider adding a section on refactor paths between Blaze and React? Ideally, something along the lines of the following:
Blaze in Separate Files <==> React in Separate Files <==> Single File React
[HTML, CSS JS] <==> [JSX, JSS, JS] <==> JS(JSX, JSS)
I opened up another thread this morning which details some use cases as to why these kinds of refactor paths are useful/important. Hopefully it will generate some community discussion. But I suspect this may need some MDG guidance as well.