request: add page and pages/collection variables to the context

[danifornells]

version

assemble v0.24.3

description

Question: I am moving assemble tasks from grunt-assemble to assemble. After doing that and having everything working, I realized that grunt wrapper adds page and pages data that helps a lot on resolving common things like navigation menu.

After struggling myself and checking spread and obfuscated docs, I suspect to found the two sources doing the jobs:

• An assemble plugin (available as a package) that adds single page data: https://github.com/assemble/assemble-middleware-page-variable
• A second assemble plugin (embedded on grunt-assemble) that adds pages/collection data: https://github.com/assemble/grunt-assemble/blob/master/lib/plugins/page-collection-properties.js

As far as I know, the main difference from assemble-core and assemble, is that the last one, besides other improvements, comes with the pages/collection feature pre-configured and ready to work.

In my opinion, having the pages/collections fully working, should include both mentioned plugins configured, otherwise you cannot have fully functional feature.

Let me know if the proposal makes sense, or correct me if I am wrong.

assemblefile.js

Assemble file is not relevant on this issue, it is just a question

[assemblebot]

@danifornells Thanks for the issue! If you're reporting a bug, please be sure to include:

• The version of assemble you are using.
• Your assemblefile.js (This can be in a gist)
• The commandline output. (Screenshot or gist is fine)
• What you expected to happen instead.

If your issue is related to one of the following, please open an issue there:

• grunt-assemble Issues with using assemble in grunt or the grunt-assemble library.
• handlebars-helpers Issues with using handlebars helpers from the handlebars-helpers library.

[jonschlinkert]

As far as I know, the main difference from assemble-core and assemble

There is some information about this on the readme.

After struggling myself and checking spread and obfuscated docs

Sorry to hear that, you could have saved some time by checking the readme first.

In my opinion, having the pages/collections fully working, should include both mentioned plugins configured, otherwise you cannot have fully functional feature.

Thanks for the input, but we won't be adding page back to the context. As you mentioned, you can add it easily with a middleware. Assemble is used for a lot more than building "pages", we made this decision to keep assemble fast and keep the context as clean as we can.

We are working on documentation, and one of the things we'll be adding is a migration guide for switching from grunt-assemble to assemble. We've also discussed publishing a plugin that adds the defaults used in grunt-assemble, so that it can be used in assemble or grunt-assemble.

closing since I think this has been clarified.

[danifornells]

Thanks, crystal clear.

• 1 for the plugin

[jonschlinkert]

after thinking about this more, I'm going to reopen so we can discuss more. What else would you like to see in assemble by default?

[danifornells]

Great to see this as an open discussion. Well, I can speak from my case, that obviously will not fit all others, but I hope can open the call for suggestions.

How I discovered and decided to use assemble? I had the needing to build a design system, and none of the all-in-one solutions was fitting my case. So I went into https://www.staticgen.com/ and I evaluated some options based on JS (Node/Grunt/Gulp). What made me choose assemble was having Handlebars as a view engine, and the lack of closed taxonomy that given the freedom I needed.

How did I feel using it? I started using assemble around early 2016 through the Grunt option, someway hacked to run with Handlebars 4. I've seen a long gap on grunt wrapper development till few months ago, and I have some projects still using the older versions and working. I tried sometimes to move to node based tasks and left Grunt, and finally just a couple of weeks ago, I encouraged myself to do it. Was hard, and my surprises originated this thread, but I have to say that now is working fast & fine ;) On that whole experience, I considered few times to move to another solution, but at the end, I like somewhat on assemble that drives me to stay.

What I would like to see on assemble? As I mentioned starting the thread, the grunt wrapper comes with must-having key features that empowers assemble as strong competitor for multipurpose static site generators. No matter if that features comes out of the box or served as a plugin, but they need to be well documented. So my wishes are:

• All you need to use assemble as static site generator like context, taxonomies, helpers, relative routing, ...
• A clear documentation on a single source of truth site, like what it is and is not, for who is built for, getting started, advanced usage, use cases, ...

I do not have a lot of time for OS, and I am investing few in other project, but I can help on documentation if you need a hand.

Would I recommend assemble to others? Sure, but not for all people or cases. Let's say, if you need a static site generator for basic stuff, chose the one closer to your stack, and if your stack matches assemble, use the grunt wrapper to start with nearly zero-time setup. Once you need more power, or Grunt is disturbing you, move to naked version of assemble, but do it carefully.

Building great tools is harder than using them, my respect to @jonschlinkert <3