Feedback / ideas for React component generator :)

[mas-who]

@jmuzina I had a look at the React component generator, very interesting stuff! Based on initial testing, I have some feedback / questions / ideas (listed below). Let me know what you think!

Feedback / questions on current implementation

1. If no path is specified, why does the generator create the component in a folder one directory back from the cwd? (../DS)
2. Is the generator intended for use within an application project or the upstream design system project?
3. Can test file generation be made an optional input? If the generator is used in a local project, the testing approach might differ. However, this would be less of a concern if we standardise testing tools across all projects.
4. For generated components, using FC<Props> type feels neater and might improve readability.
5. Does the generator account for project specific linting/formatting rules?

Ideas for future

1. Add support for theming and styling during generation. For instance, the CLI could prompt users to set up dark and light mode variants for the generated component.
2. Allow users to define a props interface during generation. The component and related templates (e.g., Storybook stories) could then be automatically configured to reflect the props. This could also extend to test templates potentially e.g. tests for different prop values.
3. Enable the generator to handle possible component states and side-effects as input parameters.
4. Add the ability to generate new components by extending existing ones. For example, a CLI flag like --from Button could create a new component that spreads and inherits props from the base Button component.
5. Consider including migration guides for updating components to conventions introduced in newer generator versions.
6. This one may not be 100% relevant for the component generator :) Once the new DS React components library is ready, it would be helpful to provide reusable code snippets for easy integration into projects. We may need to explore whether there’s a way to distribute these snippets in a tool-agnostic manner, avoiding reliance on specific IDEs.

PS: Please let me know if I chose the right category for the discussion? Since the above includes not only ideas, I chose the general category.

(Edit by @advl : replaced bullets by numbers)

[jmuzina]

Thanks for your feedbackk @mas-who! Addressing these below:

Feedback

1. If no path is specified, why does the generator create the component in a folder one directory back from the cwd? (../DS)

You are right that the component path argument is not well documented currently. @goulinkh has also mentioned this (ref). We are aiming to improve documentation of the generator parameters. The generator is not intended to be run on the current working directory, rather it is intended to be run on a directory beneath the CWD in order to properly create storybook story names and component re-exports. However, this is not currently communicated clearly enough.

The specific behavior you are seeing (logging ../) appears to be a Yeoman bug that outputs a .. when creating files in the CWD. However, files are still generated in the CWD, not one level up.

2. Is the generator intended for use within an application project or the upstream design system project?

This generator is intended for use in the upstream design system project at the moment. In the short-term, design system engineers are the intended users. In the more medium term, it is aimed at developers working on convergent architecture with similar linting rules and domain structures, so application developers can use it as well. We want everyone in WD to be comfortable contributing a component to the design system, which is why we've put out a call for feedback at this early stage. Your question raised a point, however, that we have a lack of documentation in the react core library and the generator itself mentioning these intentions and plans, which we will action.

3. Can test file generation be made an optional input? If the generator is used in a local project, the testing approach might differ. However, this would be less of a concern if we standardise testing tools across all projects.

Borrowing from point 2: as this is currently aimed at DS developers, and we have an established requirement for testing and testing framework (Vitest), we have no option for exluding tests or using different frameworks, to make sure the components added to the DS use the correct architecture choices. When this expands to cover more general use cases, it will be extended to include a more configurable test integration.

4. For generated components, using FC<Props> type feels neater and might improve readability.

This is a good suggestion. We have used React.ReactElement for our initial set of components, and have mirrored that in the generator. However, we could stand to benefit from using FC and will benchmark those choices and adjust if needed :)

5 Does the generator account for project specific linting/formatting rules?

Promoting convergence rather than divergence, so we assume for linting and formatting purposes that the files need to be formatted after generation, generally due to artifacts of code generation such as double line spacing.

Ideas

1. Add support for theming and styling during generation. For instance, the CLI could prompt users to set up dark and light mode variants for the generated component.

We are still maturing our components' theming API, so this hasn't been included in the generator - however once we have established a more comprehensive theming API it will be added to components and generators, and support both the existing light/dark theming but also more complex compositional theming!

2. Allow users to define a props interface during generation. The component and related templates (e.g., Storybook stories) could then be automatically configured to reflect the props. This could also extend to test templates potentially e.g. tests for different prop values.

I want to check my understanding here. Are you referring to extending the current default props by adding in more parameters, such as this?

yo @canonical/ds:component Button --onClick

This is an interesting question, but I would want to know more about how this would be consumed and what its output might look like. Our approach has been to create a stable starting point for components, not to automate the more specific parts of their API - would much work be saved vs having developers add a few props to the generated output?

3. Enable the generator to handle possible component states and side-effects as input parameters

Could you please provide a few examples for how you see this working? What is the goal you'd like to achieve with it, what would be some example inputs and outputs?

4. Add the ability to generate new components by extending existing ones. For example, a CLI flag like --from Button could create a new component that spreads and inherits props from the base Button component.

There is an interesting complication with this idea: what should happen if the component templates are updated, and one tries to extend a component that was generated with an earlier version of the generator and thus has less reliable props naming and structure? I wonder if this is something that can be cleanly implemented without adding too much complication, eager to hear your thoughts on the above and more about your general workflow and ideas on this topic.

5. Consider including migration guides for updating components to conventions introduced in newer generator versions.

100% agree. The generator output should follow semver conventions and every significant (minor or major) update change should be accompanied by a migration guide. I'll add this to our plans!

6. This one may not be 100% relevant for the component generator :) Once the new DS React components library is ready, it would be helpful to provide reusable code snippets for easy integration into projects. We may need to explore whether there’s a way to distribute these snippets in a tool-agnostic manner, avoiding reliance on specific IDEs.

This is something that will largely be tackled by the React components library - each component should provide some snippets that allow you to get up and running with it.

Separately, we are also maintaining work-in-progress boilerplate that provides a complete ready-to-run React Vite application that consumes design system components, that can be helpful for bootstrapping components and providing more contextual examples for component use.

Regarding IDEs, I would agree that it would be nice to have integrated code snippets, but I admit I have never worked on such a task before, and will have to look to see if there is a way to implement snippets in an IDE-agnostic fashion.

In summary

Thanks again for your feedback and apologies for the delay, we have had quite a bit on our plate this week and we're very thankful for you taking the time to share your thoughts with us, and hope you will continue to do so and spread the word to your colleagues :)