Love it! ..Idea: render method not needed; template is inferred based on component name

[faceyspacey]

you could do it in a build plugin or a wrapper around React.Component. I'm not sure how you're building sideburns, but is React.Component actually pure React or is it your own wrapped version?

..Anyway, I think making react look as much like blaze as possible and vice versa will go a long way to quell the concerns over the "React Fiasco." Excellent Job/Idea!!!!

[faceyspacey]

also, the main question in my mind has been: is there any way to make an easier abstraction for props and state???

It's a lot more work in React passing functions to child components so that they never have to deal with state, and other such "low level" tasks. To me, that's been complete and utter non-sense in React. I'm the type of developer interested in making my code be as purely representative of the business logic as possible. So React introduces all these additional essentially "tasks" you have to do to manage the technical details. That's all fine and dandy because it does great things for performance--but I'm an unconvinced there isn't a future evolution for such reactive platforms where more technical minutia can be automatically managed.

Blaze simply is way more straightforward in this regard. Helpers, events and including templates is a way smaller "api surface area" to learn. It was all we ever needed besides "components," but there is Blaze Components for that--so that's basically solved too. In terms of business logic, what React has added is way overkill. It increases the "api surface area" like 3 fold. So the question is: how can we make Blaze/React components where you're still allowed to flexibly use Session + Reactive vars (possibly very incorrectly in terms of state placement/isolation--that's up to the developer) instead of React style props/state stuff? How can we remove the props/state stuff and automatically deduce as much as possible about the most performant way to do it? I.e. generate react state/props based on the terser tracker-based model?

I realize it's likely not possible, so I'm posing the question to determine what our closest best option is. Clearly you guys must agree or you wouldn't be writing Sideburns--React makes you do lots of extra annoying shit. I honestly don't get how a lot of the React defectors in the Meteor community don't see that. They basically just seem to see React Native, and stopped thinking from there. I doubt very many of them have done any performance comparisons themselves (though we all have likely experienced where Tracker seems to combust between flush cycles and animations degrade). Anyway, they all just seem to be clamoring to superfluously be passing props and state around, when Blaze implicitly handled the props as data contexts, and essentially allowed state management to stay trivial in trial apps, while leaving it up to you for more complex apps.

For me, at least, I never needed to be told what to do to isolate state. Maybe it's because I've been using my own class-based component framework for a year now (similar to Blaze Components, but for Models as well, and general classes). So what I'm saying is: there are other solutions than all the work React has us do to isolate state-related code in a professional fashion. We dont need React to tell us what to do there. They should just admit it's "extra nonsense you must do, only for performance reasons, and we wish you didn't have to do it, but hey if you want a better 'interface' use Blaze Components, just know it won't be as fast." ..Am I getting the right idea here? Or am I missing something about what's awesome about all the extra work React has you do. Again, minus the missing Components aspect, Blaze seemed to hit the nail on the head for naturalness; for a natural fit for what you would expect, no more no less.

In short, the React interface sucks, but it's a necessary evil to achieve performance--that's the one and only true idea here, correct?

[timbrandin]

Here's my thoughts around templating for the next version; https://github.com/spacedrop/spacedrop/tree/master/packages/react-templates,

I've basically pulled out the template layer to enable for template overrides and also allow for usage of the templates in regular React code like this:

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
  }
  render() {
    return ReactTemplate.TemplateName(this.state); // <- give the template the state or props as context.
  }
}

[faceyspacey]

but why even have to to have a render method. just pass a template with the same name as MyComponent the state. use a build plugin to get the name MyComponent via a regex if u have to (i wrote this exact build plugin FYI if u need it).

[timbrandin]

And you are correct it does take more effort to build React components compared to blaze templates/helpers, but in the long term I believe building React components help us focus on one task in a component and not do everything in one template.

Regarding simplifying creating React components, I'm considering some syntax like <component name="MyComponent"></component>.

There's a great discussion on what the next Blaze should be here which I think is crucial to embed into a next version here. https://meteor.hackpad.com/Proposal-for-Blaze-2-bRAxvfDzCVv
https://forums.meteor.com/t/is-blaze-still-worth-it-supported-in-the-future/11282/15

[timbrandin]

The idea behind that is to allow React people to keep building React components like they are used to and give a simpler way for people used to Blaze to build React components using <component /> instead of through the <template />

[timbrandin]

Something that will also be important to keep in mind building this is that the future will be loaded on demand, so the thing Blaze does to add everything into the global scope is a bad practise. People will need to import it if they want to use a component/template instead.

[faceyspacey]

I guess I'd like to go farther with this and make it so you basically can't decipher the difference between Blaze code and Sideburns React-powered blaze code. But that said, I'm actually talkin about my version of Blaze Components (not based on @mitar's version, but my answer to that same problem). I'll show it to you real quick so you see how it preserves Blaze while adding some sugar:

class Toc extends Ultimate.Component {
    //life-cycle handler
    onRendered() {
        //do something
        //`this.model()` will work consistently like below
    },

    //event handler automatically inferred to be an event rather than a helper (since it starts with `click`)
    ['click #bookmark']() {
        if(!Meteor.user()) Meteor.loginWithGithub(() => this.bookmark());
        else this.bookmark(); //call a method on this component, yay!
    },

    //method accessible from `this`
    bookmark() {
          this.model().bookmark(); //model is inferred from underlying spacebars/blaze context of above event handler
     },

    //standard helper accessible in the template
    bookmarked() {
        return this.model().bookmarked; //again data context is consistently accessible at `this.model()`
    }
}

Also note that this.instance() is reliably the blaze Template instance just as this.model() reliably finds the model.

here's the ES5 version:

Toc = Ultimate.Component.createClass({ //Toc inherits from Ultimate.Component
    //methods
});

and a simplified ES5 version that doesn't highlight the inheritance used behind the scenes:

Toc = Ultimate.createComponent({ //Toc also inherits from Ultimate.Component
    //methods
});

So just by virtue of all the events, helpers, life-cycle handlers and methods being tacked on the same extensible object, you have something that looks a lot more like React. To me--and i'm pretty sure this is beyond subjective at this point--it's pretty obviously what a Blaze Component system should look like. It's pretty much what @mitar's looks like, along with some additional features he added. Right.

So that's basically where the path you're taking and the path I'm recommending diverge. Minus removing the need for a render method--which I think you could easily do as an option, and I'd love to help with--your system looks very similar to what the Blaze components system should look like. What I'm saying is I'd like to take it a step farther and just figure out how to remove the need to mess with .state and .props essentially. That seems to be the core difference. I'm not nearly as experienced with React as I'm with Meteor/Blaze, but it seems we could make a system that looks identical 80-95% of the time, even though it's operating extremely differently if we figure out how to interchange .props and .state with implicit blaze data contexts and tracker-based state implicitly reactive variables. The keyword in Blaze/Meteor being IMPLICIT. That was what was so beautiful about it. I don't want to do that extra work with React. It adds up to a lot of work. There are easier conventions to do so, and often times you don't even need to take it to that level.

So could we write a parser that generates .props and .state style React code from tracker-based blaze code? Is it even possible?? Based on your deeper react knowledge, how challenging do you see such an endeavor?

ps. my Ultimate.Component library set out to solve a lot of the problems mentioned in that hackpad article you linked, the main ones being:

-participation in the prototype chain, aka inheritance
-consistent contexts/expectations for the value of this/model/instance
-the ability to actually use this and reliably call component methods, rather than the imperative nonsense you end up with in plain Blaze; i.e. ur steered in the right direction of breaking up your functions into smaller functions

[mitar]

The keyword in Blaze/Meteor being IMPLICIT. That was what was so beautiful about it. I don't want to do that extra work with React. It adds up to a lot of work.

I think this is a contentious issue. Some people would say that this is the good side of React. (I think @stubailo from MDG shares this view.) My view is that this is like strong-typed vs. dynamically-typed languages. Some prefer one, others prefer another, and trying to move Blaze to more React style is a bad idea, because those who want strong-typed (explicit) should use React, and those who prefer dynamically-typed (implicit) should continue using Blaze.

similar to Blaze Components, but for Models as well, and general classes

BTW, I also have models package. And Blaze Components were made so that they can be attached on top of those modes (or any other).

Just for the record, there is a design decision behind the fact the Blaze Components use its own components and not template instance in methods. The reason is that I wanted to decouple logic from template. So that one can change template of the component, or reuse template between multiple components, or can extend a template and add different logic.

[faceyspacey]

yea @mitar I love your work, it has inspired a bunch for me.

I also agree with your metaphor of strong-typed vs. dynamically-typed. And hold the strong conviction that strong + static typing adds zero value to "product." If you don't need it for performance, it shouldn't be in your tooling/languages. Same goes for the react tedium you're expected to do. The best counter argument I've ever heard is that typing allows for tooling (i.e. IDEs) to better autocomplete and infer various things. My response to that is that tooling can parse comments, and you can optionally talk to the IDE via such comments, not required types. This sort of programming rarely suffers from type-based bugs where you receive a parameter of the wrong type--so that whole argument is just non-sense. It just always has seemed to me people that come from the strong + statically typed background who can't let it go. So to me, my--i guess--subjective opinion is that react's equivalent of "strong typing" is complete and utter bullshit. But only if we can accomplish similar performance and "X Native" without it. If all the hoops you gotta jump through to manage state in React is truly the only way to truly needed performance, well then I'm wrong. That's the quandary I'm posing here.

Likely, everything React does is unnecessary. A better way just hasn't come along yet. I think the first step is just realizing how natural Blaze is, and getting people to realize that maybe there is more hype surrounding React than they realized. React Native has done the most to fuel the hype. Ever since that came out, everyone blindly dropped any reservations about React and immediately jumped ship.

Basically, if there is ever a time to fight for Blaze, now is the time, or it's gonna die. And that's a shame--because interface-wise, Blaze destroys both React and Angular. What do you think we should do @mitar?

[timbrandin]

I've also considered solving the state/props paradigm, but ended up with the conclusion that having props is an amazing way to pass along parameters to a component, but at the same time the sharing of contexts in sub-components in blaze is very useful it could be really hard for anyone else to reuse that particular component as it has dependencies to other outside components.

But sure, template-wise I'd like it to be simpler not having to be aware of where the data or helper is coming from, may it be the props or state, I just don't care when I make markup and styling, that should really be done behind the scene to simplify things.

I'm all for having both @mitar and @faceyspacey plucking my code apart, and if this ends up being Blaze 2, I hope MDG and @stubailo gives us lots of creds for it at that point.

[mitar]

So I think we should try to differentiate Blaze from React. So making Blaze the same as React is in my opinion wrong and useless. People can just use React then. But there is a space for Blaze. As I explained, a non-strict typed templating enginge. So this is why I think we should let it be and just fix some issues and take good ideas from others as they come around:

• components (Blaze Components solved this)
• good animation support (Blaze Components does this, hopefully)
• allowing to have templates and code in the same file, for those who want this (sideburns), I would really love to see this integrated with Blaze Components #20
• allowing to bind events by annotating elements in the template (but which should not leak to rendered elements), Binding event handlers inside the template peerlibrary/meteor-blaze-components#99

Just after that I would say that we would need to think about performance, see if we want to change backing rendering engine and so on.

So for me it would be interesting if somebody would build on top of Blaze Components a preprocessor for templates inside the same file. And that event binding at the same time. Sadly, I do not have time to look into this at the moment.

What we get then is a nice upgrade path templates -> Blaze Components -> having files together and better event mapping. And I think this solves most of the issues people brought up in Blaze 2 proposal, except for the implicit data context. But I would leave this as a feature people can use, but they do not have to. With Blaze Components there are many other ways you can build inter-component communication. I do not think we should prescribe only one. Maybe it would just help fixing/providing this:

• Easy way to force no data context in templates meteor/meteor#5459
• Spacebars: Objects/ Array as arguments meteor/meteor#5095

Then people could decide and do explicit data context:

{{> Foo ()}}
{{> Foo foo=(a=value)}}

Or, we could provide a base class which ignores the parent data context if it is not provided explicitly, and people could do:

class Foo extends ExplicitBlazeComponent

{{> Foo}}

So people can then choose how their component should get stuff. And it is easy to pass explicit stuff as well. I think this is the best of both words.

BTW, see peerlibrary/meteor-blaze-components#82 for an idea of alternative way to communicate between components. What I am mostly using in my work.

Sadly, I do not have time at the moment to implement/fix any of things above, so it would be great if somebody would build this upon Blaze Components. I can help with Blaze Components part if there will be any need there.

So my TODO for Blaze 2 would be:

• allowing to have templates and code in the same file, for those who want this I would really love to see this integrated with Blaze Components #20
• allowing to bind events by annotating elements in the template (but which should not leak to rendered elements), Binding event handlers inside the template peerlibrary/meteor-blaze-components#99
• Easy way to force no data context in templates meteor/meteor#5459
• Spacebars: Objects/ Array as arguments meteor/meteor#5095
• fix other Blaze bugs as reported (rendering order Parent onRendered triggers before child's meteor/meteor#4410, Template.instance() inside autorun Tracker.autorun inside template.autorun should make sure Template.instance() works meteor/meteor#4494)
• find a way to do this Find a way to pass arguments to methods which are included peerlibrary/meteor-blaze-components#12

[timbrandin]

I might have some time during this week or next weekend, I also have to backport react-templates into sideburns too and I could take a look at this at the same time.

Feels like we're onto something good here, solving issues for more than the meteor community too I hope. :)

[timbrandin]

Just updated master with some new capabilities such as better handling of templates and events, and also now using the .html and .js extension to actually reduce what needs to be modified to have a working version of the Blaze and Spacebars API running in React.

I created a video showcasing what that could look like compared to an example meteor application meteor create example without any changes. Here's that https://www.youtube.com/watch?v=3qZbmGA-JcI

The only modifications I've made to the sample app is removing ecmascript, blaze-html-templates and adding timbrandin:sideburns (and kadira:flow-router-ssr to gain SSR). I also had to replace Session as it doesn't work on the server. Also notice I've commented out the Meteor.isClient as we're able to render on the server now.

I hope you're as happy as I am we've gotten this far, which I would presume is halfway to support everything in Blaze and Spacebars so that we then can continue working on new Blaze 2 stuff.

Btw, If you test it out, notice the brand new feature of template, helper and events overrides by simple just defining the thing once again below using the loading order to determine which to use (last one always wins).

[stubailo]

Curious, what are you doing with 'js' files?

[timbrandin]

I'm using it to read the Template eventmaps before the templates are compiled, and to be able to add these in the react template by searching for the selector and appending the react event attributes.

[mitar]

This looks amazing!

Hm, one thing I am looking into is how could we extend Blaze so that things like <button onClick="onClickButton">foo</button> could work. This would call onClickButton event handler on the component/template. I do not want to add some automatic IDs or classes. Do you know if it is possible to bind event handlers directly to elements somehow with jQuery? Or will we have to call addEventListener manually when rendering?

[timbrandin]

I would add a step in the ReactRegex that gives us that feature by compiling down to what is allowed in jsx syntax and bind the function to the component and all that, and there's no jquery necessary for that. Here's all the compiling steps: https://github.com/timbrandin/react-templates/blob/master/react-regex.js

[mitar]

Hm, I was thinking of implementing this also in Blaze 1, just to see how it works inside Blaze Components. But maybe we can go directly in React. :-) Looks pretty simple.

[timbrandin]

Yep, I would do it first in React, and see if we like it!

[timbrandin]

@faceyspacey I noticed your phase 2 additions in your fork, could you clean it up and add what we've talked about in a PR?

[faceyspacey]

ok, it was just a to do list. I'll remove the Blaze 2/Components stuff and clean up the list so it just has stuff relevant to current Blaze. I'll do the Template.contentBlock.

[timbrandin]

Perfect! :)