-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Re-using core parts with sourcejs-react-styleguidist implementation #43
Comments
I’ve added a todo of things that can be done. Overriding particular components is already possible but not documented. |
Thanks, looking forward! After polishing upcoming releases, I will come back to it, and will try to help improving re-usability on styleguidist side. |
Changing entry file is also possible via Webpack config but is a bit complicated. Something like that: updateWebpackConfig: function(webpackConfig, env) {
if (env === 'production') {
webpackConfig.entry[0] = 'newentryfile';
}
else {
webpackConfig.entry[1] = 'newentryfile';
}
return webpackConfig;
} |
Hi, Could somebody please re-check todo list of things to be done? I'll be updating my integration plugin around the end of the month, could help with improving your codebase following chosen strategy. |
Looks like we have the first and the last. |
Probably related #107. |
The most important things are done, feel free to submit pull request for everything else you might need. |
Hi,
As I noticed before in twitter, I've recently made a fork of this repo, creating SourceJS integration plugin - https://github.com/sourcejs/sourcejs-react-styleguidist. This allows to combine all the best from styleguidist features, and SourceJS platform. Demo example of how it works could be found here https://github.com/sourcejs/sourcejs-react-bundle-example.
I changed quite a few things to make integration possible, but it could be a big pain to sync both version in future, so it's better to think which parts we can re-use. I really believe collaboration is the best option we can choose, allowing to contribute to common toolset from both parties.
Would be great, if we can elaborate on it and think which parts could be improved with more flexible configuration, and which components would be nice to decouple from the main repo.
Code and high-level integration description is available in the plugin repo https://github.com/sourcejs/sourcejs-react-styleguidist. Here's a slight overview of my changes and some thoughts about potential re-usage approach:
Changed entry file
sourcejs/sourcejs-react-styleguidist@1fe97fc
Updated
src/index.js
file, so it could handle different model from styleguide-loader. This is done to render component example per SourceJS spec, because we separate component documentation into different pages.I also use there
components/Playground
directly, since I need only rendered component example and editor.Re-use solution: allow to define custom entry file from styleguidist configuration.
Changed styleguide and example loaders
https://github.com/sourcejs/sourcejs-react-styleguidist/blob/54884721235709a97b65dadbfec557d9853cd1ec/loaders/examples.loader.js
Since I've needed custom data model to pass into entry file, I've changed
styleguide.loader.js
, to keep file re-usable, we can probable exposecomponents
key renderer function to configuration.Few small changes were also done in
examples.loader.js
primarily toreadExamples
function, which should be also overridable.Re-use solution: expose rendering functions to configuration, so they could be overridden.
Updated Playground component
sourcejs/sourcejs-react-styleguidist@ead8127#diff-7fe7badfce237da87bab50760526fd30R27
Using custom entry file, we will be able to override any UI components to approach our needs. This should be useful also for theming the styleguide.
Changed config.js lib and webpack config
sourcejs/sourcejs-react-styleguidist@ead8127
I can move my changes from
config.js
to other abstraction later on, so here's nothing to be changed in the core.Changes in
utils/utils.js
can be handled by just making util functions more robust, and allowing them to accept Object or Array.Todo
setComponentsNames
andglobalizeComponents
should accept objects as well as arrays.The text was updated successfully, but these errors were encountered: