Flux in meteor is repetitive and needless? I think subscribe and publish and miniMongo, has completed many thinks that flux do, I was wrong?

react
1

Flux in meteor is repetitive and needless? I think subscribe and publish and miniMongo, has completed many thinks that flux do, I was wrong?

In the view, if we triggered an event, changing the contents of the database, this time, all subscribe to the components of the relevant data, will trigger an update, it seems that we do not consider the problem a lot of data flows. Based on this idea, I now try to subscribe to and publish data on the top most parent part, when the sub-level components mounted, call the parent class method and pass parameters, the parent access to relevant data, and then through the props passed down to the sub-level components, benefits of doing so is that when the sub-level components are uninstalled, the data remains in the parent component, then the component level if and when the child opened again ,it has initial data last stay in the parent’s, if this data desired no change with the last,according to react features, components are not updated,No waiting time the page is loaded.

Now I has a problem is that sometimes subcomponent will be like a parent requests data, in general, may use a callback to complete, but if the intermediate subset of components and parent assemblies nested multi-component, can only transfer layers the method of the parent component, then the callback many times?Seemingly need a more direct communication way between the components, but it does not need to follow the flux way.

Is there any better way?

2

Problem with React without Flux/Redux etc is in the fact that you need to pass params whole way from top to the final template.
And in current official Meteor integration it means re-rendering the “controller” component and all it’s childs for every 1 change in monitored reactive sources.

In Flux/Redux etc you dont need to pass props million levels and also you re-render only what really changed, can track if component should re-render based on immutable match.
And if you want to keep some kind of cache it should not be problem to code it too.

2 Likes
3

More clear explain that I had read of.
Thanks @shock

4

Thank you for your answer, if you use flux in meteor, seemingly do not need [ReactMeteorData] react mixins official now offer, is that so?

5

The MDG official integration is in the component inserted a trigger controller update, but did not provide a suitable component communication way, React official says communications can user flux, oneway data flows of react more adept at rendering a view, at this time, how to choose?

6

IMO it’s time for MDG to have an opinionated opinion on complicated front-end data management. @sashko

1 Like
7

Sry, but this almost threw me off my chair xD

Anyways, just wanted to mention that improvements to Tracker would be a big step forward in better management of data… IMO

I really want to embrace React, but Tracker just doesn’t run correctly in it, as the current integration mixins are too… Shallow, compared to using it with Blaze

8

In Flux/Redux etc you dont need to pass props million levels

I use manuel:viewmodel Share feature for that. I grab the data inside of shared object, then specify on a template level which shared objects should be accessible. If the data changes, this change is noticed by all the templates that need this data and only by them.

9

There is a lot of overlap in Meteor and they can be used instead of flux/Redux. The main things these lack is a strict structure, both accomplish the same end goal.

1 Like
10

Thank you for your answer, if you use flux in meteor, seemingly do not need [ReactMeteorData] react mixins official now offer, is that so?

Not necessarily. You still need a way to reactively update your view based on changes to the database.

It is also super easy to reactively update the view when there is a state change in another component by combining flux with ReactMeteorData.

For example:

MyComponent = React.createClass({
 mixins: [ReactMeteorData],
 getMeteorData(){
  return {
    someAppState: State.get('someAppStateSetSomewhereElse')
  };
 },
 render() {
  return (
   <h1>{this.data.someAppState}</h1>
  );
 }
});