In the soon-to-be-released Meteor Guide we have a section on building reusable components with Blaze, which takes some pointers from React, like internal state, validation of arguments, and more: http://guide.meteor.com/blaze.html#reusable-components
Awhile ago, I remember you mentioning that your motivation for writing the validated-method package was that you experienced the necessity to write a lot of boilerplate code to write methods using best practices (validation, testing, etc.). There were also some less-than-obvious features that were exposed, such as returning the stub value by default.
I was wondering if you experienced anything similar while writing/studying for the reusable components chapter. Any discussions about doing something similar for reusable templates? Do you see any value in that? Maybe something along the lines of having the validation “built in” to the template rather than having it sit in the onCreated callback. I also don’t want to miss out on any secret features!
I hope this isn’t interpreted as a request or anything like that. More curiosity than anything. The guide is getting the gears spinning in my head… and it’s not even done yet.
Similarly, gaps in the platform highlighted by the guide can often be plugged by community packages; we hope that if you see an opportunity to improve the Meteor workflow by writing a package, that you take it! If you’re not sure how best to design or architect your package, reach out on the forums and start a discussion.
That’s one of the goals! We hope that by highlighting common issues, we can expose some of the gaps that can be filled by carefully constructed packages.
I’d encourage you to:
Make your package small, so that it can solve one problem very well
Get a lot of feedback from people in the community about the design and see if it works for them