foundation-cli
foundation-cli copied to clipboard
Improvements for installation of blocks and kits
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~~
Some other things I had in the back of my head
- Allow listing blocks by category
- Allow searching blocks with text
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?
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
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.
@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
@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?
@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?
You want to take a pass on that?
Yes!
EDIT Also, going to try harder to keep PR's atomic.
@kball
Allow listing blocks by category
Done.