assemble / assemble-handlebars

Assemble engine plugin for Handlebars templates
https://github.com/assemble/assemble
MIT License
8 stars 19 forks source link

Web components with Component and Assemble #21

Closed ismay closed 10 years ago

ismay commented 10 years ago
Background

In this issue: https://github.com/assemble/assemble/issues/524, the use of Assemble for a sort of webcomponents briefly arose. I'm now experimenting here with whether html, css, js components could be managed with component whilst compiling the html templates with Assemble (since the #extend, #block and #content helpers allow for a way of defining separate components).

Issue: Component cannot compile assemble style hbs templates natively

As far as I know component cannot compile assemble style .hbs templates natively (the compilation of css and js works just fine). So I have to choose which way to go. The options I can see are:

  1. Not use html components at all (and just include a html style guide with every css/js component). Which would mean more manual maintenance.
  2. Skip building the templates when using component build and build them with Assemble instead.
  3. Use a builder plugin for component to allow it to compile the (Assemble) handlebars templates.

Option 3 would make the most sense to me but is also the most ambitious. It would make sense because the hierarchy of the different components could be handled by component, which is what it does best. Option 2 would not allow for that and would be a bit more bulky.

@jonschlinkert mentioned aiming for a way to use web components, and going for a more decoupled approach. Which direction would you take this experiment given the upcoming changes to Assemble? Would option 3 even be possible with the way Assemble is structured? I'm interested in what you (the creators of Assemble) have to say about this approach and whether it fits your intended use case for Assemble.


I hope that this isn't too vague of an issue. It is more a question about architecture concerning the use of Assemble, and I apologise if this isn't the right place for it. I know that the issue also concerns component, but I felt the main issue was with assemble. I would really appreciate any discussion on the subject!

jonschlinkert commented 10 years ago

Hi @ismay! thanks for the awesome and well-thought-out question!.

I'd like to propose a new way of viewing the situation. Everything is a trade-off, so maybe start by deciding what you are willing to give up and what you aren't. Also stay focused on how you actually see yourself using the tools you're mentioning. e.g. don't forget that developer convenience will play a huge role in how well your ideas actually come to fruition.

As for my personal opinion, I think the biggest challenge and barrier to achieving what you want "context". Not philosophical context, but the challenge of passing the right data to the right component based on where it's used. That's really not very challenging in isolated use cases, but when you need components to be flexible, modular, portable and reusable across projects and with other as-yet-unknown components, it gets much more challenging.

I want to say more, but for now I'll leave at this, we're going to be releasing the next version of assemble very, very soon. And we've had some interesting developments that I think will help you with this goals!

I'm going to close this, but I really would love to keep this dialog going, so please feel free to create a new issue on the main assemble repo. Maybe when we announce the next release! thanks! great ideas!

ismay commented 10 years ago

Thanks for the quick reply and the advice! I'll try the second option for now (skip building the templates when using component build and build them with Assemble instead), and will keep an eye out for the release of the new version of Assemble. Maybe that'll be the key to a more closer integration with component. Looking forward to it!