-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic discovery of components to include in freestyle guide #176
Comments
@lukemelia the reason why we're not colocating the files is that we don't want to ship them with the production app, and having them in an in-repo-addon means that we can disable the addon for the production build. maybe I missed it, but that does not seem to be mentioned in the plan above? 🤔 |
@Turbo87 Thanks for that reminder! This is something I discussed with @chrislopresto but didn't make it in the doc. I have now updated. |
This issue lays out a plan for adding automatic discovery of content for the styleguide.
This plan takes some inspiration from @Turbo87's blog post Autodiscovery for the Ember.js component playground but imagines a different approach then outlined in the post.
The goal is to reduce the friction and busy-work of adding and updating components to your freestyle guide. Specifically, it allows for colocating a "freestyle" component with the component is is demonstrating and removes the need to edit the main freestyle.hbs template, which otherwise can become unwieldy in large apps.
There are two parts of the plan:
There are also number of related ideas to improve the experience further.
Here are some details on the above, followed by a step-by-step plan:
1) Build-time discovery via ember-cli hook
ember-freestyle will discover components from app's file structure at build time. This will be implemented via the
preprocessTree
hook and a configurable set of path patterns for which matching files will be considered components to be included. Those component names will be written to a "manifest" module for consumption at run-time.The proposed default file path patterns are:
app/components/**/freestyle/component.js
app/components/**/freestyle.js
app/components/freestyle/*.js
TODO: What additional patterns, if any, are necessary to support:
The manifest module will be named
-freestyle/discovered-components.js
and export an array of the discovered component names.2) Run-time generation with a component and service pair
The
ember-freestyle
service will be updated to import the manifest module that is generated at build time and expose it as a property nameddiscoveredComponents
on the service.A new component will be provided by ember-freestyle to allow including these discovered components. It will looks like this in the generated freestyle.hbs template:
This component will iterate over the
discoveredComponents
array from the service and use thecomponent
helper to output each component.Related ideas
The preprocessTree hook should also be able to remove match components for production builds based on a config flag. This allows an consuming app to get the benefits of freestyle in development, without a size or load time penalty in production.
Currently, all freestyle entries need to be wrapped in the
freestyle-usage
component. This creates some annoying boilerplate and we would like to make this optional for these auto-discovered components. The same goes for withinfreestyle-collection
'svariant
blocks.There is a strong likelihood that the work required fo this plan will allow us to improve the efficiency and robustness of the snippet finder code used by ember-freestyle. We can also move sass and js snippet parsing to a plugin as it is not used frequently in our experience.
Another idea, likely suitable for a plugin, would be to allow automatic generation of freestyle components via ember-cli-prop-types data and an AST traversal.
Detailed implementation steps:
usage
?)Other ideas:
The text was updated successfully, but these errors were encountered: