Blaze best practices

blaze
1

As it seems from the other topic that Blaze is alive and well, good working horse only without blows and whistles, I would like to gather best practices to use it properly (without ending in spaghetti code) and current projects, which power it up.

3 main I can think of are:

ViewModel by @manuel https://github.com/ManuelDeLeon/viemodel/
Blaze Layout by @arunoda https://github.com/kadirahq/blaze-layout
Blaze Components by @mitar https://github.com/peerlibrary/meteor-blaze-components

All increase speed of development but you can expect slow down in application speed - https://github.com/ManuelDeLeon/viewmodel/issues/290 which I think is not a problem because enough for MVP, and if you go beyond MVP you can hire developer to refactor it in anything else )))

Any other practices/tools/comments? What do you actually use in your work?

2

I think Blaze Components is/was the true “next step” for Blaze, if it wanted to move in the direction of React’s props/components/etc. pattern. ViewModel was good if you like binding, but to me there was a big tradeoff once your app grew in complexity.

I think if I were to really try to work with Blaze again, I’d try to extend it myself. I think there is a lot of good stuff in Blaze Components, although it is sometimes opinionated, I think. There could be some nice core things, like knowing how autoruns are being triggered, etc. that would really improve the dev experience if they could be implemented.

I know qualia have released some nice tooling/devtools around Blaze. Have a look at their stuff, too?

1 Like
3

I found the Blaze guide to be a very good source of best practices

It is a little thin on how to componentize your templates though, which I think is a pretty key concept to keeping your code under control

Some more options for state management wouldn’t go astray either!

4

BlazeLayout's sole purpose is to support rendering for routers like FlowRouter. It’s not really a framework that makes componentization easier in Blaze.

Regarding the other packages, ViewModel and BlazeComponents: I read lots of good comments about them, so they seem to be very good, and I also know that Manuel and Mitar are known for supporting things well.

However, I decided for myself to stop using any community packages that would cause a major refactoring if I had to remove them, which is quite obviously the case if they are defining the way you set-up your UI.

I’ve seen too many community packages all of the sudden causing problems in my app, because they had been abandoned by their original maintainers and were not compatible any more with more recent Meteor versions. This is not to blame the package authors, they sometimes had to find “creative” ways to workaround Meteor limitations when they built them in the first place. But as a package user, you never know if one of these creative workarounds would cause app breaks in the future. And they are very hard to track down sometimes.

When I first read in a skinnygeek comment that he followed this best practice, I thought it might be too harsh. But I learned over time that he was absolutely right.

Still, BlazeComponents and ViewModel should be one of the “safer” packages, since they seem to be maintained well. But if you’re really considering using them, I think it would be no big step further to use React or Vue instead. And then you can be somewhat sure that you’re on a framework that will stay for a while, because both of them have been adopted by the wider JavaScript community. Another plus is that you could move out of Meteor at some point of time and still keep some of your front-end code.

1 Like
5

Yes, that may be always the problem of ‘solo’ authors. I have come from VCL desktop world where there once a lot of companies maintaining paid packages and web world seems to be plagued to me by hippie way ‘let all be free’ but in the end this free cannot be maintained well by single persons. If you compare it to business, such state of things favors big corporations and venture companies and kills small and medium software businesses (

Who sells something in Meteor world? Only @msavin And that’s sad because free lives as long as someone else or something else (day job, university scholarship or likes at the forum if one accepts such currency) pays for it.

But at least in CSS world you can find decent maintained UI packages, which are sold. Seems like they exist also for React.

6

Here are my top three suggestions:

  1. Do not store arrays of data into reactive variables, because whenever you update as there is no way to distinguish which items or fields were updated and which were not, and that will make Blaze go crazy.

  2. Use local minimongo collections to store complex data and arrays of data. Minimongo will create individual trackers for each field and item, and it can tell which items in an array were updated because it automatically assigns an _id field

  3. When returning data to minimongo, filter out the fields that you do not need to prevent unnecessary tracker instances being initiated. For example, let’s say you want to render a list of your user accounts, but the documents are huge, and you want to optimize the performance:

<template name="userList">
	{{#each user}}
    	{{_id}}, {{joinDate}}, {{profile.name}}<br>
    {{/each}}
</template>

Template.userList.helpers({
	user: function () {
		return Meteor.users.find({}, {
			fields: {
				"joinDate": 1,
				"profile.name": 1
			}
		});
	}
})

Bonus suggestion: get familiar with the Blaze API!

4 Likes