Add observable wrapper for meteor data subscriptions as addition to meteor-data-mixin

[istarkov]

In new react apps ES6-ES7 javascript syntax become very popular. But there are no mixins for react components created as ES6 classes.
It looks like it's not a big deal to create observable wrapper for Meteor subscriptions (using RxJs contract or any other) and use it as like as any other observable.
Since that your meteor-data-mixin get's more easy code, and users can use this observable to create HoC components and decorators as like as this https://gist.github.com/tgriesser/d5d80ade6f895c28e659

For example this code line https://github.com/meteor/react-packages/blob/master/packages/react-meteor-data/meteor-data-mixin.jsx#L20 is not a good solution (props can be freezed using 'Object.freeze' in any version of react), and this code can easily be avoided by using normal observable subscriptions.

There are a lot of additional usage behaviors if Observable subscriptions will be created. Like as subscription caching, counting etc...

[dgreensp]

I think a wrapper component is a great idea to supplement the mixin. By using the mixin to implement the wrapper, the code would be very short, and an app could reasonably have a few different kinds of wrappers used for different purposes. We're not quite ready to write an official, universal wrapper/HoC, but we're open to suggestions of what it should look like.

HoC are pretty new, and sadly, all the syntax I've seen for invoking them is pretty ugly, except for "ES7 decorators," but those are too speculative right now to transpile (there are a couple possible specs, and it's not even clear they will be in ES7, now called ES2016). That said, I expect some people will want to use HoCs now.

One of the React core team members pointed out that wrappers that set props.data don't compose well with each other, and called into question wrappers that modify props and pass them on: facebook/react#3398 (comment)

About Object.freeze: We don't mutate props, we just temporarily swap the pointer in this.props. React can't prevent that, because they have to assign to this.props themselves. You can still freeze the props object if you want.

We're interested in adapting Meteor reactive data sources to Observables, especially if the proposal goes through to make Observables a first-class concept in React.

[grigio]

It seems that mixins are a bit controversial feature in React. https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750

[dgreensp]

@grigio Yeah, I've been following a lot of the conversations. Dan Abramov's sensationalistic headline has caused a lot of confusion.

Mixins aren't dead; everyone still uses them. ReactRouter switched away from them, and then switched back, saying they misread the situation. It's true that the React community wants to move away from mixins, but it hasn't happened yet. Maybe in six months they'll be more dead. Right now, if you ask the React team how to avoid mixins and still achieve X or Y, they will say, "Just keep using mixins", or, "We never told you to use ES6 classes".

React's ES6 class syntax is actually a bolted-on feature. Internally, React still uses old-style classes and mixins. In the farther future, the bleeding edge pattern may be to avoid classes altogether in favor of a purer functional programming style (see some very interesting thoughts here: facebook/react#613 (comment)).

React's refusal to implement a mixin scheme for ES6 classes is purely a matter of principle, in that mixins are an OO feature and the whole point of supporting traditional JS/ES6/CoffeeScript/TypeScript classes is to be less opinionated and not invent custom OO. In theory, you have any number of solutions to deal with the fact that ES6 classes don't come with mixins. You can use a third-party mixin library. You can use inheritance. You can hack prototypes. You can wait for ES to get mixins or traits. None of the choices are that great, however.

So React is making people choose between their ES6 and their mixins, and there is no right answer. The more you love ES6, the more you are inclined to hate mixins now.

However, given that mixins are not going away as an implementation technology, the great thing about having a mixin is you can use it to write a wrapper (and then use ES6 classes and composition), or you can use it to directly inject data into any component. It's a smaller building block than a class or a function that creates a class.

On the subject of directly injecting data into a component, that's what the Observe API does, which was proposed by Sebastian Markbage — the React core team member quoted in half the above links, who seemingly spawned the whole HoC meme. So make of that what you will.

See also: http://react-in-meteor.readthedocs.org/en/latest/meteor-data/#why-we-decided-to-ship-a-mixin

[istarkov]

I haven't use mixins for last few months. (I wrote a lot of react code and even publish some)
And i understand that in some situations mixins are really helpful.

And yes!, to create HoC, decorators etc i can reuse code you provide, but having Meteor data sources as observable object i also can reuse other code i use.

For now i have an idea how to use react with meteor, but still have all that nice features as like as hot reload, code linters and style i like.
(I've never wrote on Meteor and all i need from Meteor now is just a Data)

I've not tested it yet but the idea is simple - just to attach webpack generated script (which can be hosted by webpack hot-dev-server) from meteor side, and passing some Meteor globals to this script, (It's client only and will not work on server)

something like this

Meteor.startup(() =>
  $.getScript(PATH_TO_MY_SCRIPT, () => {
    window.__init_and_render_react_app__({Meteor, Tracker, Session, ...etc });
  });
);

Then i can write react apps as i always did.
And the first thing i'll write (if this idea work) be the rx like observable wrapper for meteor data.

PS:
For me your code looks like as a react for meteor developers and i need meteor part for react developer :-)

[dgreensp]

Hi @istarkov, regarding your PS, that is a good observation. It's true, our initial release is geared towards existing Meteor developers, and that has guided which features we release first. We're going to keep working our way along the curve, though, to entice more React developers to Meteor.

I encourage you to share the results of your webpack integration work with the Meteor community.

[tmeasday]

We've created a straightforward HOC wrapper. Other wrappers would be great! (maybe as separate packages that build off react-meteor-data.