Home

Welcome to the meteor-blaze-components wiki!

from crater.io

I itsetai 19 hours ago 1 points Reply Awesome! Is there any reason to use React with meteor over Blaze anymore? J jj227 18 hours ago 1 points Reply server side rendering I itsetai 17 hours ago 2 points Reply Fair. So, for a commercial application or one with a lot of users its maybe best to use React. But, for a simple project where performance difference is negligible it's better to use Blaze. J jj227 17 hours ago 1 points Reply for sure, i'm using blaze and this looks cool, i'm excited to see some packages use it. M mitar 7 days ago 12 points Reply I made a JavaScript version of the tutorial: http://components.meteor.com/ A AppShore 7 days ago 1 points Reply Thank you! Richard Lai 6 days ago 1 points Reply YAY! L luisherranz 6 days ago 1 points Reply Superb. Thank you :) D Daler 2 days ago 1 points Reply Thank you, Mitar, indeed! M mizan 2 days ago 1 points Reply Thanks !! Max Savin 7 days ago 14 points Reply The tutorial should be in JavaScript since that's familiar to everyonr S satyavh 7 days ago 8 points Reply Seriously dude, this author made a brilliant package and you're telling him what he should do? You should learn Coffeescript instead and thank him for spending all his time on making this package. Besides the documentation has lots of plain javascript examples to figure it out. C camiel 7 days ago 10 points Reply Very serious dude, there's been quite a lot of discussion lately and following general consensus about not using CoffeeScript for guides & examples.

There are plenty of reasons why but the main reason is that the Meteor community is small enough that if you want your open source package to be adopted you shouldn't start off by keeping a large portion away from it by not explaining it in the majority used language. Almost everyone that knows CoffeeScript knows JavaScript as that's what they started out with, while quite many know JavaScript but no CoffeeScript. When new to Meteor there's plenty of stuff to learn to not also have to get familiar with a new language.

It's like telling fresh immigrants to the US from Europe that to be able to get a drivers license in the US you need to know Spanish. They've got plenty other stuff to learn on their plate already and it just doesn't really make sense to having to learn Spanish for a drivers license even though many people in the US speak Spanish and it such a nice language to speak. CEOGavin 7 days ago 7 points Reply "You should learn Coffeescript instead" - not a valid argument :) S satyavh 7 days ago 2 points Reply I know, as invalid as saying docs should be in javascript A AppShore 7 days ago 6 points Reply This is a valid remark. Javascript is the standard language of Meteor. Coffeescript is a dialect used by a minority. There are developers from all around the world in the Meteor ecosystem. If each of them was using his own language instead of english this will be a mess. David Burles 7 days ago 10 points Reply Looks nice Mitar, just unfortunate that it's coffeescript M mitar 7 days ago 6 points Reply It is only implemented in CoffeeScript. It is JavaScript. You can use it from JavaScript. M mitar 7 days ago 4 points Reply I added an example in JavaScript and ES6: https://github.com/peerlibrary/meteor-blaze-components#javascript-and-es6-support L luisherranz 7 days ago 1 points Reply Thanks for the work you put into this and thanks for the example in vanilla JS.

I understand people frustration when they are "forced" to learn CS to use (or just understand) great packages like this. Please, consider adding tabs to display all the examples in JS and CS.

Even some people of the MDG prefer if documentation is in JS (or both JS and CS): https://forums.meteor.com/t/easier-viewmodels/1265

Anyway, thanks again :) M manuel 6 days ago 4 points Reply Thank you for this. Excellent package and documentation. It has given me a lot of food for thought for my ViewModel package. I think I'll add a "change" binding to specify a function that will run when the bound value changes. Other than that I think we're achieving the same goals by different means. Although I should emphasize on my documentation that you can use ViewModel to create reusable components more.

As for Coffeescript... sigh. I used to make fun of .Net developers for their hatred towards Javascript. I will never do it again after seeing how Javascript developers hate Coffeescript so much. I posted an example (~10 lines) in Coffeescript and I think I would have gotten a better reaction had I posted a picture of me eating a baby.

My recommendation is to accept the fact that this community is adverse to Coffeescript and meet them where they are, not where you want them to be. At the end of the day your documentation is for this community, not for you (you already know your package inside and out). So I'd suggest you make your documentation use Javascript as the default language and Coffeescript optional. M mitar 6 days ago 1 points Reply Can I suggest you one thing. ;-) You might want to implement ViewModel on top of Blaze Components. So just extend the BlazeComponent and add data binding, so that users do not have to call events method to register events. Maybe ViewModel could even be simply a BlazeComponent mixin. M manuel 6 days ago 1 points Reply What would that achieve? M mitar 6 days ago 1 points Reply That people could use both? M manuel 6 days ago 1 points Reply That's what I don't get. The projects overlap so much that I don't see the benefit of using both. M mitar 6 days ago 1 points Reply The only difference I see is that you prefer data-binding approach while Blaze Components do not do anything in that space. So I see this as a perfect combination. Blaze Components take care of how things are rendered and structured, and ViewModel provides a mixin which data-binds forms to methods provided by Blaze Component, and back. M mitar 6 days ago 1 points Reply And to answer the CoffeeScript discussion: don't feed the trolls. M mitar 6 days ago 1 points Reply BTW, have you seen Blaze 2 proposal? M manuel 6 days ago 1 points Reply Yeah but I don't see anything that would make me want to stop using ViewModel. It's a step in the right direction though. S spicemix 3 days ago 1 points Reply I have to say, I prefer ViewModel to Blaze Components at least at this point. I really don't see much value in chrome for its own sake; everything in my world revolves around the data model (other than the CSS I suppose) and I was attracted to Meteor because it's so data-driven via the reactive architecture.

So a UI framework has to be built around data binding otherwise it's just left floating in space to me. It's data models that get re-used and chrome is merely decoration upon them. ViewModel at least conceptually makes this all make sense to me and I have no idea why it hasn't caught on. (But then I haven't tried it yet)

Thanks for having this discussion as I was unaware of your Knockout knockoff Manuel. I just wish you had more integration examples with more sophisticated contexts so I would know the party doesn't end abruptly at some point. I don't really see how it would be a problem yet but then I don't see it won't. M mitar 3 days ago 1 points Reply Sure, this is why I am proposing that such data-binding could be a mixin. So that people can choose the paradigm they prefer. S spicemix 3 days ago 2 points Reply Maybe that's too little opinion for me.

I think a key differentiator is between application developers and library developers. The reason I like Meteor's package system is I can compose apps with it. The reason I dread it is I've found to build applications properly you sometimes (often?) need to factor them into packages. I would really rather not.

Blaze Components seems aimed at library developers, whose components will then get composed by app developers who shouldn't need to know anything about Blaze Components just like I hoped to avoid knowing anything about the package internals.

Making your code re-usable is often a false god for an app developer (though it's the entire point for a library developer). You can waste an awful lot of time making a reusable widget that never gets re-used. I would need a must-have to learn some library-writing framework when I'm busy trying to build an app.

So I guess the title of this post, "reusable components for Blaze" is a misnomer as I see no components for my apps, I see a framework for library writers to write those components. I suppose that's like Polymer? I have no interest in Polymer for my own writing. If someone has cool widgets and it's easy to integrate them, I will take a look. If you've enabled that then that's great. Have I read this wrong? M mitar 3 days ago 1 points Reply We use those components exclusively for writing apps. :-) It makes it just so much cleaner, even if you do not reuse them. S spicemix 3 days ago 2 points Reply "Cleaner" is a vitamin. I'd need a painkiller. M manuel 2 days ago 2 points Reply Thanks for the feedback. I'm in the process of updating the documentation with a lot of items I'm picking up from this conversation. Can you provide an example of a more sophisticated context? In practice, view models tend to be simple because you usually break down your app into small components/templates, each with it's own view model. A large view model is usually a smell.

A valid question is "What if I have a template where I can't do what I want with ViewModel?". The answer is simple: The worst thing that can happen is that you end up with a template coded "the Meteor way". What normally happens is that you use plain Meteor code to support ViewModel when you can't bind to an element. For example, if you have a fancy button created in JS and you can't apply the bind (or it would be too cumbersome to hook the bind). You can just add an event:

'click #fancyButton': function() { Template.instance().viewmodel.doSomething() }

The rest of the template is handled normally with your view model and binds.

The biggest advantage of ViewModel is having near zero ceremony/crap/fluff in your code. The view model is just a plain old JS object and it consists of "just your code".

As to why it hasn't caught on, your guess is as good as mine. I think people see less code and think "Oh, this must be a code generator, autoform, kitchen sink, whatnot." ViewModel doesn't do any of that, you just need less code when you use a view model. S spicemix 2 days ago 1 points Reply Thanks Manuel. I think you've done a great job and ViewModel solves a lot of Blaze problems. Though this whole discussion has made me look at React/JSX/Harmony etc. and I'm not sure how much Blaze I will end up using in practice.

There's a big bump in the learning curve migrating to React, but there's also a (smaller) bump going to Blaze Components. I would say ViewModel has the simplest learning curve of the three and if I use Blaze I will seriously consider that. But React has an aura of inevitability right now as being a standard JavaScript (and native!) component solution so I would think the learning curve is worth it.

As for example code, not arguing for bad architecture, just something a bit more complex than leaderboard and contacts. A more significant schema with more complex behaviors. I know it's nice to have concise examples but it's also nice to show conceptual scale. emiliano 7 days ago 5 points Reply awesome package dude! and man, I don't understand this CS vs JS nonsense, both are pretty similar and easy to read! S satyavh 7 days ago 4 points Reply This is brilliant, it's exactly what Blaze was missing and why people are looking for alternatives like React. I personally like Blaze a lot because of its philosophy of plain html templates and separate javascript controller. Whereas with React you have to write html in javascript (which in my opinion is a very bad idea). Blaze feels more pure, React adds this level of complexity that is not necessary.

Thanks a lot for making this! CEOGavin 7 days ago 3 points Reply Thanks mitar. Awesome work. Though I am not sure where I'll get to use them. I struggle with Coffeescript but thanks to http://js2.coffee/ I was able to make sense of it ;) H hexsprite 7 days ago 5 points Reply Looks awesome. And i'm happy its in coffeescript! Can't wait to try this out and start to refactor things in my projects... L logician 4 days ago 1 points Reply Thanks for the contribution! Love the CoffeeScript too. sivli 6 days ago 1 points Reply This is wonderful! I spent the day trying them in one of my younger projects. I am seriously tempted to switch all my projects over to this. Not to plug but a huge selling point is how well they work with my shadow models. Very clean separation of concerns. M mitar 6 days ago 1 points Reply I am using components with my own PeerDB. You can even mix them together and use both. :-) Sacha Greif 7 days ago 1 points Reply This looks pretty cool. I'll have to think about where I'd use component inheritance though, so far Telescope is relatively flat. M mitar 7 days ago 1 points Reply Even when it is flat it makes code much more organized and easier to maintain from my experience. Also, it fixes some issues with scoping of data contexts and keeps components around much more than template instances. I think it is just easier to develop.