It seems like the GitHub - getflywheel/local-components: Reusable React components to use in Local by Flywheel! repo has been archived as the components are now included within a Local WP monorepo. Whilst this makes sense for the Local engineers, it makes it very hard for people (like myself) who are actively trying to develop an addon, as we can no longer see the APIs for components.
The Local Addon docs point us to Storybook, but as you can see from this example (@storybook/cli - Storybook) there are no docs available and therefore engineers have no idea what props a component can accept.
Are there plans to improve the documentation, or make something else available for those developing addons?
Thanks,
Daryll
Bumping this, since it doesn’t seem to have been seen and the issue still stands
Hi @darylldoyle - I appreciate your concerns and would love to help you get the information you need!
While the repo has been archived, nothing has changed as far as what’s available in the package we publish to npm. I notice we’re even packaging the original Typescript source files at the moment (e.g. the Button component can be found at /node_modules/@getflywheel/local-components/src/components/buttons/Button/Button.tsx).
Even if we were to exclude those TS source files from the package, which I believe to be pretty standard, we will always include the type declaration files (.d.ts) for those components. I would highly recommend using Typescript and modern Typescript tools such as those built in to VS Code to access the prop API’s for our components. This will also help prevent any runtime errors when you try to run your add-on.
All that being said, the ideal front-end component library has both accurate Type files and thorough, example-driven documentation. Our Storybook leaves much to be desired on that front. There is an ongoing effort to improve our Storybook using Storybook Controls, which should help surface the props and their effects.
Some follow-up questions for you:
- Can you specify how the repo being archived has impacted your specific workflow or is preventing you from accessing the prop types?
- Are there specific components you are trying to get information for/would appreciate updated Controls stories for first?
1 Like
Hi Adam,
I appreciate your reply and will try to explain the issues I’ve encountered.
Whilst the type definitions are great, and I’m using TS to build out the addon, seeing the available props doesn’t always give a complete picture of what can be done with a component. Sometimes, the naming of a prop can be obscure, and it’s helpful to jump into the source to see what it actually does.
I’ll admit, I didn’t realise that you were packaging the .tsx files. I assumed they’d have been stripped out, so I didn’t look for them there.
I also think the naming of components doesn’t always make its purpose clear; for example, TableList vs TableListMultiDisplay vs TableListRepeater. In these cases, again, I was jumping into the source files to see the differences.
Storybook-wise, documenting those argTypes and enabling the Controls addon would be super helpful, especially if you could include descriptions for args with ambiguous names.
One of the big issues I’m running into is determining which components to use for certain use cases. I’m getting there, but it’s a lot of trial and error to see if it looks and works as expected. Again, this is a problem that a well-organised and documented Storybook instance could resolve.
I’ve seen the improvements to Storybook recently, and I really appreciate that effort. I think if I were prioritising that work, I’d start with the more niche components; it’s fairly trivial to work out how to use a button, but working out which table component should be used and when takes more time.
Thanks again for the response,
Daryll
I agree, it can be confusing to know what to use when. I’ll take a look at those niche components and see if there are opportunities for improvements. It’s worth noting that for a lot of those more niche components, the original source code that you’ve cloned or can read on the archived repo will likely stay relevant and helpful for quite some time - a lot of it hasn’t been touched in a long time.
I was a little surprised to see the TS source files in there as well, so hopefully that will also help in the meantime!