Skip to content
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

Closed
4 of 5 tasks
robhrt7 opened this issue Nov 17, 2015 · 7 comments
Closed
4 of 5 tasks

Comments

@robhrt7
Copy link

robhrt7 commented Nov 17, 2015

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 expose components key renderer function to configuration.

    Few small changes were also done in examples.loader.js primarily to readExamples 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

  • Allow to define custom entry file from styleguidist configuration.
  • Expose rendering functions to configuration, so they could be overridden.
  • setComponentsNames and globalizeComponents should accept objects as well as arrays.
  • Allow to pass config via the API as well as via a file.
  • Document components overriding.
@sapegin
Copy link
Member

sapegin commented Nov 17, 2015

I’ve added a todo of things that can be done.

Overriding particular components is already possible but not documented.

@robhrt7
Copy link
Author

robhrt7 commented Nov 17, 2015

Thanks, looking forward! After polishing upcoming releases, I will come back to it, and will try to help improving re-usability on styleguidist side.

@sapegin
Copy link
Member

sapegin commented Nov 21, 2015

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;
}

@robhrt7
Copy link
Author

robhrt7 commented Jan 12, 2016

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.

@sapegin
Copy link
Member

sapegin commented Jan 12, 2016

Looks like we have the first and the last.

@sompylasar
Copy link

Probably related #107.

@sapegin sapegin mentioned this issue Sep 20, 2016
@sapegin
Copy link
Member

sapegin commented Oct 6, 2016

The most important things are done, feel free to submit pull request for everything else you might need.

@sapegin sapegin closed this as completed Oct 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants