I’ve done some work to make sure that it plays nicely with meteor, but I haven’t had the time to get it 100%.
The reason for this package is simple. A lot of people like JSX. I personally have found that JSX works fine for small templates, and larger “dumb” templates work ok too. However, one limitation that I continue to hear is that JSX doesn’t work well for environments where UX and UI are different people (as is often the case in larger more traditional teams).
For that reason, having an alternative lowers the barrier to entry for react. You can still leverage all of the wonderful things that react offers while having your templates be much much closer to plain HTML and comprehensible by design-centric developers and designers.
Should you use this for all components, maybe, maybe not. It was designed to work well with the package system, so you can definitely export components with this technique and it will not mess up someone else’s environment. I haven’t had a chance to test it at all, it is really an early alpha version (tests have NOT been written yet). Feel free to try it out and give feedback. Feedback that I don’t want to hear is “Why not just use JSX.” I already answered that, and while I understand the logic of JSX, it’s not for everyone. This provides an alternative that people in more separated environments can use.
I would love to hear more from people on these teams. I hear this a lot as a hypothetical concern, but I haven’t ever talked to an actual designer about it.
I’ve also heard it more in the hypothetical. However, I have at least one team mate who is adamant about the same thing even though he does understand javascript.
One of the more common examples I hear often is the bootstrap navbar, which is a thing that is commonly used by more traditional websites (some of which are moving to Meteor as well). To do the bootstrap navbar in React as is, it requires a lot of components to make sense of it all.
Another example I hear frequently is loops in general. It is true that JSX has no direct loop construct which almost every other templating scheme in existence has. Not only that, but for developers coming from almost any language other than javascript aren’t used to functional loops (_.map, _.each) and for loops look funky in JSX.
Who I’d be interested to hear from is someone on one of the aforementioned teams who has transitioned to React and either JSX or plain javascript and how they handled it.
Either way, there is an alternative, and this works pretty well with Meteor and React. The source code is on github, but I have to get that link added to the versions on atmosphere (I’ll tackle that tomorrow, I really should be asleep right now…)
It’s not so much a developer vs. designer role, but more “someone with e.g. html skills” and “someone that understands the bigger picture of the app”.
So creating great UI’s, is a lot of times still a pure html/css way of thinking. Of course with a bit of js sprinkled on top. But a nice workflow could incorporate a way for the “dude” that know animations, transitions, css, etc. from heart, but has no idea about lifecycles, components, etc.
That kind of flow was common in blaze, and is actually exactly how the company I work for operates. Our UI guy just didn’t want to, or couldn’t learn the helpers stuff (though he’d used handlebars extensively). So he makes pure html concepts and I slice and dice them to create the UX.
I’m going to weigh in here, in favor of separation of concerns. We do a lot of non-trivial, enterprise-level Meteor development at my day job, and we value maintainability across a team of front-end devs (each with their own specializations and strengths). In truth, the lack of a templating system for React has been the major thing holding me back from really sauntering up to the bar and drinking the KoolAid. From our team’s internal analysis, the lack of separate templates was the one Achilles’ Heel that – prior to this package – gave Angular 2.0 a slight lead over React in one crucial area. If this package works as advertised (or can be tweaked to do so), then this makes the Angular vs React a complete no-brainer. With React templates, I’ll take React – with server-side rendering – any day of the week.
If I understand the technology properly, this package lays the foundation for grafting Infernojs into a React-API compatible, templates-based ecosystem, except (according to benchmarks), this technology leapfrogs everything else out there, and is about 34 times faster than React. Speaking of no-brainers…
I realized after my last post that I hadn’t quite articulated this: Thank you, thank you, thank you, for spending the time and energy grafting this package into a Meteor package (along with some tasty improvements!). If you hadn’t done it, then it would’ve been a while before I could’ve camped out on such a project. As a result of your work on this project, I can spend more time on learning React and Inferno. WOOT!!!
Hmm… digging into this a bit more, and this looks like it could be a very nice refactor step after ReactBlaze.
Blaze > BlazeReact > ReactTemplates
I think I’m sold. The rt-if, rt-repeate, rt-scope, and rt-template directives should be just enough to replace {{#if}}, {{#each}}, {{#with}}, and {{>foo}}.
Actually, you might not need BlazeReact at all. Or BlazeReact could conceivably be refactored so it compiles to react-templates. I’m a big fan. Happy to have this as a compare/contrast for when we begin refactoring to React in a few weeks.
As an aside… the designers I’ve worked with who have managed a migration to React… one was let go from one project A, and the one on project B kept their head down and when React didn’t deliver native performance the team decided on an iOS rewrite. Neither were particularly great outcomes for either designer or either team.
Without a template deliverable, the designers are stuck delivering screenshots; and since they’re not involved with code, expectations begin to diverge and communication breaks down.
It’s very alpha, and I haven’t tested rt-template at all yet or made sure it plays nicely within Meteor. However, including other React components by class is as simple as <Foo /> You can also pass properties to that other component <Foo propName="propValue" />
I believe the point of rt-template is more along the lines of {{> Template.dynamic template="foo"}}
The big thing that I wish this had was an “else” for rt-if, rt-repeat, and rt-scope although you can create an else just fine by inverting and passing to rt-if but a built in else would sure be nice. I may fork the node module and implement that.