Feedback Appreciated: JSX Templates

react
41

@sacha I actually kind of like this idea, and it’s what I would have done if it was up to me to implement templates on top of React. If the transformation is simple enough, it could be worth it to have it just for your own apps, since it looks like it is pretty low-cost to maintain. But it looks like people want to go with the “React way”, which means writing the JavaScript boilerplate.

1 Like
42

@arunoda what I want to understand, is do you think functional stateless components are a good idea? If yes, how is that different from what I’m doing? And if no, then why?

From tweets like this one:

I would’ve thought splitting off the JSX part of components would be a good idea to work towards?

Glad you like the idea! But I guess I still have a hard time understanding what fits the “React way”…

43

Some more info I found about functional stateless components:

As it turns out, “functional stateless components”, “functional components”, and “stateless components” are all different (although related) things.

44

Awesome. I’m definitely using this.

Now I won’t have to tell my designer to look for HTML codes in files full of Javascript.

IMHO, there is nothing wrong with the name ‘templates’. After all, JSX is (in simplest terms) JavaScript + HTML (which is compiled into Javascript, but it is still HTML), and when you put variables in HTML, it becomes a template.

Also I believe it should not make any difference if the component is functional or not, stateless or not. When you have designers, HTML people, backend people, and a separation of development roles, it is a big plus to be able to put the HTML in another file. It is a big plus even when you are a single developer, it helps with separating logic from presentation.

1 Like
45

Although I can see the benefit of this if you component was literally just going to be a render function w/ no logic or imports, I think things get a bit weird once you start doing anything more complex. For instance I feel like control flow is out of place now:

myTemplate.jsxt:

<div>
   <h1>{props.title}</h1>
   {props.showSubtitle && <h2>{props.subtitle}</h2>}
</div>

Maybe it’s fine, but you can see how could start looking at lot like JS anyway pretty quick. That’ll lead you down the road of wanting to define an <If> component, etc, and sorta-inventing a template language.

Imports are more problematic. How do you import SubComponent from './library.js'? In 1.3 globals are a thing of the past.

When we were considering an approach like this I toyed with some “components” that could do syntax (or destructuring, which was another nice thing you mentioned). But I think either you end up defining a template language (which could be very simple, and perhaps have value), or the end result just ends up being a garbled 90% of the JS file you would have started with.

1 Like
46

Yeah I can see now that this is where this probably leads. Probably not enough benefits to introduce an additional layer of complexity. Still, it was an interesting experiment (and also surprisingly easy to create thanks to Meteor’s build process API : )

1 Like
47

Just for completeness’ sake, I’ve updated the package to handle modules, propTypes, or any arbitrary JS code before or after the main JSX block. Also updated the documentation to make it clear this is more of an experiment and not necessarily a good idea:

48

To what extent? Exports have to get attached somewhere. Are they just attached to the Meteor scope? What happens if a package author has an object Foo that they want… at the global scope? Or is 1.3 simply not going to have any automatic linking of files? In that case, how is it different than plain node again?

49

The no globals thing will be optional in 1.3 but certainly the canonical way to do things moving forward. So a package wouldn’t put Foo in the global scope, you’d need to do import Foo from 'meteor/packagename'

The idea is not to be different to plain node, where possible. Although there are still lots of differences (ES2015 modules, the concept a package which is different on client and server, etc).

1 Like
50

Hmmm, that doesn’t necessarily sound like an improvement for most of my clients. Their focus is much more on medical informatics than it is on the scaling, performance, or view layer. So they tend to prefer Jade, Coffeescript, and other abstracted languages on the other end of the abstraction/transpilation spectrum. Linking files with import/export is going to be seen as a big step backwards. :sigh:

2 Likes
51

CoffeeScript also supports import and export, by the way. And there are many improvements like static analysis and easier refactoring that you can only get with explicit imports that I’m sure your clients will be interested in down the road.

2 Likes
52

Will modularization help my Blaze app or will I see gain like code splitting only with React?

53

Oh, it’s not that they don’t appreciate that there’s any value in it. It’s simply a matter of available staff and skill sets. Between a dev or project manager that knows HTML/CSS/JS and React/Angular/ES2015 versus a dev that knows HTML/CSS/JS and is a Nurse or RadTech, they’ll take the person with medical knowledge over the one with technical knowledge.

So our clients and stakeholders are really keen on the following workflow:

A) receive wireframes from a physician
B) a lab tech or grad student converts it to widget.html and builds a basic prototype
C) the prototype is handed off to devs/consultants with more programming skill
D) they install timbrandin:blaze-react and renames widget.html to widget.jsx, which compiles the prototype to React, while still using HTML and Spacebars, and autogenerates whatever basic import/exports are common to components
E) we can then look at the transpiled React code that was produced, and swap out the HTML file for the newly generated code. Just like we do when we’re handed Coffeescript and transpile it down to Javascript.
F) the new code will be unoptimized however. So this is where JSX Templates come in. We need a best practice for the next step in that optimization process.

This whole process is coming at JSX from the other direction, of course. We like the idea of JSX templates because we’re going to receive HTML/CSS/JS, and would like a refactoring step that produces JSX/JSS/JS.

54

You get a lot of the benefits regardless of your view layer - most of your app logic is in JavaScript, not Blaze-specific template files.

Look for more information about how to lay out your blaze app with modules in the Meteor Guide alongside the 1.3 release.

2 Likes
55

Thanks! :slight_smile: I’ll be waiting then.

1 Like
56

nope, you’re making false assumptions. but I would call it a component, had MDG chosen to. That would make more sense in the context as a discussion, wouldn’t it?

=

Not to my surprise, you didn’t actually answer me, when I asked if my answer was satisfying.

Stop being rude, and stop trying to teach me some kind of misguided lesson about something I’m not actually talking about.

57

And I think of a cat as a ginger one with fluffy hair. But it doesn’t really change the fact that the black one is a cat too.

58

Yeah - I should’ve made my point in terms of Blaze and React, and not components & templates, I guess…

2 Likes
59

Not to my surprise, you didn’t notice when I addressed that point.

Finally.

2 Likes
60

sorry for being a total ass :sunny: