We want to refactor Button component in a way that uses styled-system similar to what we did for Box here in this PR.
gutenberg/packages/components/src/button/index.js
The aim is being able to test that we can apply its styles using props. But we should be careful about keeping it backward compatible. What does it mean to keep it backward compatible? Well, currently themes rely on tag names as well as class names to be able to override existing styles we use. So we shouldn't cause unwanted regressions on themes. In order this to happen we should keep classes applied as the same way. Fortunately this is looks easy, styled-components allow it and we already demonstrated how to inject the already existing css into it here.
1st iteration(only effects web version):
Allow passing style via props to Button on gutenberg repo
Refactor a few places Button is used and pass the style via props, 3 sample cases would be fine.
Remove unused css from .scss files but keep the class names applied to Button as themes might be using those
Other Button instances should keep on working the same
2nd iteration:
Another PR to demonstrate that the Button API works on mobile too. Currently the props on mobile and web are pretty different. At this point choose some props that mobile doesn't support, like isDefault, isLink, add mobile side implementation in button/index.native.js for them. Currently there's no use case on mobile using these props so you can create a new test block(or add them to an existing simple block) just to demonstrate them using the example app.
This is the second iteration on https://github.com/wordpress-mobile/gutenberg-mobile/issues/1386
If preferred this work can be based on the existing experiment branch: https://github.com/WordPress/gutenberg/pull/17614
We want to refactor Button component in a way that uses styled-system similar to what we did for
Box
here in this PR. gutenberg/packages/components/src/button/index.jsThe aim is being able to test that we can apply its styles using props. But we should be careful about keeping it backward compatible. What does it mean to keep it backward compatible? Well, currently themes rely on tag names as well as class names to be able to override existing styles we use. So we shouldn't cause unwanted regressions on themes. In order this to happen we should keep classes applied as the same way. Fortunately this is looks easy, styled-components allow it and we already demonstrated how to inject the already existing css into it here.
1st iteration(only effects web version):
2nd iteration: Another PR to demonstrate that the Button API works on mobile too. Currently the props on mobile and web are pretty different. At this point choose some props that mobile doesn't support, like isDefault, isLink, add mobile side implementation in button/index.native.js for them. Currently there's no use case on mobile using these props so you can create a new test block(or add them to an existing simple block) just to demonstrate them using the example app.