it’s pretty clear that Blaze has no built-in concept of argument definitions
I don’t grok this at all. Will someone please provide code examples?
1 Like
Another interesting question would be, “If you are tempted to move from Blaze to something else at this point, what is tempting you?” That would yield information that would be interesting as far as prioritizing things in the roadmap.
For me, the biggest thing is SSR. I’m developing an app where a large part of the content will need to be indexed by Google, and the prospect of easy SSR in React is very attractive.
I’ve held off switching so far because ViewModel makes developing in Blaze a real pleasure, but I see now that @manuel now has a React version out, so that’s a big barrier lifted.
2 Likes
Explicitly pass parameter :
{{> myTemplate item=myItem}}
Implied parameters.
{{> myTemplate}}
In this case of implied parameters, if this template expects a data context property called “item”, it assumes a variable named “item” has been declared and set in a parent or ancestor template data context.
this is from the guide here : https://guide.meteor.com/blaze.html#name-data-contexts
<!-- bad: inherits data context, who knows what is in there! -->
{{> myTemplate}}
<!-- explicitly passes empty data context -->
{{> myTemplate ""}}
It’s analogous to this :
function stuff(item){
console.log(item);
}
stuff(22);
versus doing this :
var item = 22;
function stuff(){
console.log(item);
}
stuff();
More generally, here’s a good talk about “Don’t Look For Things” :
In my opinion this video illustrates a programming style similar to the new buzzword “Dumb Components”, which I feel like just means pass things to the constructor versus go out and fetch them from inside your component.
5 Likes
Thanks for this. When using templates as smaller components (for instance a input field in a form), I pass parameters like this for the most part:
{{> inputControl name="firstName" title="First Name" placeholder="John"}}
Here’s a slightly more complex call:
{{#with checkboxState "middleNameDNA"}}
{{> inputControlCheckbox
name="middleName"
checkbox="middleNameDNA"
title="Middle Name"
checkboxClasses="checkbox-click-event display-na"
placeholder="Test"
inputValue=input
classes="caps"
tooltip="tool tip text"
dataTooltip="First letter must be capitalized."
disableValue=disabled
}}
{{/with}}
So @sashko, when you said “it’s pretty clear that Blaze has no built-in concept of argument definitions”, did you mean that the way I’m passing in arguments here is optional?
I can’t say if this is what he meant, but Blaze doesn’t have anything like (optional/required) PropTypes in React for data type validation, which is one way of defining what you expect/accept from your arguments. If that’s what he meant, it’s not just about which args appear, but also what type they are. You have to use something like SimpleSchema (like in the example @looshi provided from the Meteor Guide). Not a big deal, but maybe Blaze should have some default, integrated solution. You could go further, validating values, scopes, etc, too.
Yes, this is indeed one of the advantages I have clearly notices when comparing Blaze with React… Together with the very rich events system: https://facebook.github.io/react/docs/events.html
Pretty much. Also for more context (no pun intended lol), Most of my issues came from systems that were in the Meteor 0.5 era with Iron Router with a router full of reactive business logic, Session all over the place, and a fair amount of the Tracker autorun. There were no patterns of template variables back then. I also came from writing Backbone apps which were very imperative and heavily used DOM state (classes, text content). Blaze lets you do imperative stuff that’s hard to maintain (like Backbone itself).
There was no best practices as no one really knew what the best way was to build. No it seems like there are much more straight forward patterns. A lot of them are based off of React’s component mindset.
Right before switching to React I made a {{Input name="firstName" label="First Name"}} sort of template that included a bootstrap wrapper, label, and self validating error messages. This came from being inspired from React. It also sounds like you’re doing something similar.
I honestly think that if you could hypothetically take the lessons of React… rewind 3 years and use Blaze that way, with strong conventions then Blaze would be an attractive view layer. It really does want to be declarative like React (and works best that way).
Also, is there no such concept as Globals in React? How are the majority of bugs caused in React, by not reasoning about where data comes from and where it’s going?
There is, sort of. Not in React but as a library, like flux, redux, mobx, etc. There is this.context and it’s frowned upon because it breaks the functional programming methodology of React (passing arguments to functions, or passing props to components). A lot of times there are tradeoffs where this makes sense but it takes away from the predictability of functional programming.
No tweaking and no code rot occurs with React?
It does. The areas where i’ve had the most issue with is any kind of ‘shortcuts’ to make things less verbose (flux, reflux, minimongo-cache, and to some degree redux, though not nearly as much if used within reason). I also only have 2 React apps over 1 year old still in prod so I don’t have as large of a sample size… but coming in months later the parts that are explicit are easy to modify and haven’t suffered from as much rot. The parts where I did flux badly (mostly async stuff)… not so much.
For example, I have a template that’s just a form input field, with styling and logic within. I use this on every form, multiple times per form. When I first built the template (aka component), I found I needed to make changes more often to it. When I made a small change, instead of changing every input field of that type in all my forms in all my templates, I made a change to one spot and it propagated everywhere. That to me is an example of productivity and maintainability. Is it any different with React?
This is very much the same thing! In fact I wish the was the standard Blaze way. When I first switched to React I had 50-100 line components because that’s how I did it in Blaze… thinking of it as one page template instead of 10 smaller components (whether they’re re-used or not).
So it is possible to write
React code too. I worry about not following the right path if I transition to React.
I think you’ll be right on track honestly. I’ve done a lot of client work in other Meteor apps and 95% of them are not built the way yours are… it’s more like smash it together quickly and hope it works later.
Doing anything the ‘functional’ way is the best all around way to use React, even if it may be more verbose. Breaking down into components is also usually an issue for new comers. It’s more obvious to make a thing that’s reusable everywhere a component but it’s not as natural to break down a page into several small chunks.
I read about containers of components, and where data should be feed into.
These translate to Blaze templates and template JS files pretty well. The template script file holds all the data handling, stitches together things and passes them down as a helper (like fullName or something) and the pure component is much like a Blaze template… simple logic and html/css. It’s just a lot easier to have child components in React than Blaze so you end up writing more of them.
Having said this, I too have recently looked into making the switch to React, but not for any of the virtues you sited. Not because of productivity or maintainability or how easy or not it is to reason about. Having a large application, I have no real issues with any of the above and my clients are very happy with my turn around speed.
It may be worth staying with Blaze for a while then. I don’t think it’s going to stop working in the near future. As long as Meteor can still compile it, things should be good.
3 Likes
I see similar patterns evolving in my work too. For instance:
{{> textInput label="First Name" id="firstName" class="name-input" value=currentUser.firstName}}
<template name="textInput">
<div class="field">
<input type="text" disabled="{{#if disabled}}disabled{{/if}}" name="{{id}}" id="{{id}}" placeholder="{{label}}" class="ui input {{class}}" value="{{value}}" >
</div>
</template>
Outside of the issues with DOM performance (which will hopefully be addressed by incremental dom), I think the “significant improvement” that Blaze needs is really just a set of solid patterns that can be realized out of what Blaze already is.
I think part of the problem with Blaze is that it’s really too easy to use. It was at least a year before I opened up the Tracker docs, and even longer before I started developing real reusable components in Blaze. With React, you’ve got a framework designed to build components. It’s possible in Blaze, but obviously nowhere near as straightforward.
3 Likes
IMO if everything in the Blaze Guide was built into the framework directly, it would be kick-ass: http://blazejs.org/guide/introduction.html
4 Likes
@msavin there’s one option missing:
- I have never used Blaze
A few people may have started using Meteor recently and begun with React or Angular, having never touched Blaze.
Alternatively, some people may have even participated in this survey having never developed in Meteor at all!
There is something that is very important for a part of the community to admit : Blaze AND React are both very cool.
I use both of them, and it all depends on my project.
I do my cordova apps with React, my personnal projects are in blaze because it fits perfectly both the time I can give to it and the performance needed, etc etc.
It’s not all blaze or all react, it simply depends on the complexity, cost, time, team, etc etc of the project I’m doing.
13 Likes