Improvements for installation of blocks and kits

[paxperscientiam]

Kits and blocks are a super idea! I wish I had known about this before.

• [x] number each item in list printed to stdout (see #62 )
• [x] allow for installation by index number. e.g.: foundation blocks install 42
• [x] Allow listing blocks by category (--sort flag)
• [x] Allow listing kits with blocks as sub-items (--details flag)
• [x] Allow searching blocks with text
• [ ] indicate which blocks/kits have been included in the "current" project when listing or more explicit command.
• [ ] abstract out common functions
• [ ] add a "contains" sub-command or similar for kits
• [ ] ~~option to un-zip~~

Cybernetics:

• [ ] foundation-cli should warn end-user if attempting install of block (or kit) into non-project directory, whiling following up with a suggestion given knowledge of root directory.
• [ ] ~~where ought these files be installed? Default should remain. However, what about assisting in placement? Specific directories for this and that. EDIT: seems that there are relevant abandoned features~~

[kball]

Some other things I had in the back of my head

• Allow listing blocks by category
• Allow searching blocks with text

[paxperscientiam]

Some other things I had in the back of my head

I think this is a good idea. I could set a flag for sorting by categories (after implementing the logic!). Something like foundation blocks list -c.

Allow searching blocks with text

Could you specify a use-case?

[kball]

Sure... the main items I was thinking were for searching on things that are somewhat category-like but not listed in our current categories...

e.g.

foundation blocks search dropdown foundation blocks search css-grid

If you take a look at the search code on the site, it's currently searching across name, category and tags (https://github.com/zurb/building-blocks/blob/master/src/assets/js/search.js#L47) though one could imagine even exposing description content to the search

[paxperscientiam]

Hi @kball , I like the idea, though I think I'll need a little help getting started.

For instance, it's not readily apparent to me how to adapt the code of lib/commands/blocks.js so as to store the JSON in a variable consumable by both listBuildingBlocks and installBuildingBlock.

Could you shed some light on that? Thanks.

[kball]

@paxperscientiam Good question... the simple approach is to continue to fetch it each time you run a command that needs it (shouldn't be too bad - these are static files so the fetch should be fast)... To do this what I'd do is refactor listBuildingBlocks to separate the fetch & parse from the logic around what to do about it... essentially define something like

function fetchBuildingBlocks(callback) {
  // do-the-fetch-and-parse {
    callback(results)
  //
}

function listBuildingBlocks(args, options, callbacks) {
  fetchBuildingBlocks(function(blocks) {
     // do logic around which blocks to display
  })
}

Let me know if that pseudocode helps or you'd like more detail

[paxperscientiam]

@kball I think #65 is what you were suggesting? It works, but it's not elegant.

Are we wanting to move from callbacks to promises with something like bluebirdjs?

[kball]

@paxperscientiam I was thinking more of the parsing & url logic inside the fetchBuildingBlocks fn, right now it's just a pass through, but that's starting in that direction.

I'm happy to move to promises; as we treat this as a location for more logic and interaction that would definitely help. You want to take a pass on that?

[paxperscientiam]

You want to take a pass on that?

Yes!

EDIT Also, going to try harder to keep PR's atomic.

[paxperscientiam]

@kball

Allow listing blocks by category

Done.