Frontend style and/or component framework

[juliacanzani]

I've been tinkering with an idea to create a frontend style framework with the goal of:

• Setting standards for good UI practices
• Providing basic helper classes to speed up frontend development time
• Bringing consistency to our plugin frontends
• Making our plugin styles less likely to interfere with other aspects of our users' sites, and making it easier for users to restyle themselves
• Perhaps bringing us a step closer to being able to provide users with a settings panel to manage colours and other aspects of our plugins' frontend interfaces, something perhaps like this: https://www.figma.com/proto/d3lM92gl1qRHbA6fX0zNTK/MemberSync-(formerly-MemberDash)?page-id=0%3A1&type=design&node-id=1345-11233&viewport=-3874%2C3034%2C0.31&t=HX5F9ogGq9cIivdI-1&scaling=min-zoom&starting-point-node-id=1345%3A10480&show-proto-sidebar=1&mode=design

@nicolas-jaussaud and I have chatted about it a bit, he thought it would be cool if this could be implemented as an NPM module, and had some suggestions for postcss plugins that could help us with prefixing: https://www.npmjs.com/package/postcss-prefixer, https://github.com/ryuran/postcss-variables-prefixer, https://github.com/postcss/postcss-simple-vars

You can see an example of an early version of the framework in use in a functionality plugin for a client here.

I think we will want to component-ize the styles so that they can be selectively loaded as they're needed: buttons, tables, tag pills etc. and it could make sense to pair this with a React component framework eventually.

I can also think of some interesting potential enhancements: perhaps colour palette shades could be programmatically generated from a base colour, or users could opt out of parts of the framework and use functional/layout styling only.

Let me know your thoughts @eliot-akira!

[eliot-akira]

Thanks @juliacanzani - Great, we can get started on planning and implementation.

(Looks like the bayside-features repo on Bitbucket is not accessible to me, the link returns 404 not found. EDIT: Nevermind, I was logged out, I see it now.)

---

The feature sounds well-suited for this new Framework module, which is meant to be included in all Tangible plugins eventually. But we can also create a new repository for it instead, to make it easier to work on.

Recently I prepared a tool called git-subrepo that finally achieves what I wanted with the code organization of modules shared across plugins. Any module can be developed in its own repository, synced to/from a parent module, and can contain child modules.

It should help with managing parallel/collaborative development, and keeping issues and pull requests organized for each module separately, instead of all in one place like Gutenberg which has dozens of modules (each published as its own NPM package).

---

One thing I'd love to figure out together is how to set it up so that it's easy to develop and contribute, not only for devs but all team members. Having a Git repo is one of the few requirements - it can be edited directly on GitHub or using a GUI app, but that can still get technical, like resolving possible merge conflicts.

Another aspect is the compilation and bundling of CSS/Sass and JS. That step requires installing Node.js and running the build command in the terminal.

These complexities limit who can contribute to development, and create a divide between devs and designers so that every change requires a request and response, instead of a designer just making changes as they see fit - that immediacy ("without mediation") and tight feedback loop allows for much greater momentum. I wonder how we can reduce the friction and learning curve.

---

Yes, automatically prefixing CSS classes and variables would be valuable for encapsulated styles that work on any site without conflict. Using PostCSS means we'll definitely need a build step. Maybe we can try with plain CSS + PostCSS plugins, which can achieve most of what Sass can do.

component-ize the styles so that they can be selectively loaded

Great idea, I'd love that. I've been thinking something similar for the Tangible Fields module, to allow loading only the field types as needed, instead of all fields' scripts in a single big bundle like ACF does. It would be easier to do this if we design it like that from the start. We'll probably prepare a "core" bundle with common/shared styles that all components can depend on.

settings panel to manage colours and other aspects

Right, this is getting close to what we've been discussing for the Template System. It can store such style variables (palettes, themes) as JSON, and generate CSS/Sass variables for use in templates. Ideally we can save duplicated effort by designing common features as a Style Engine.

We can get some ideas from Gutenberg, where they're working on a Style Engine to be merged into core.

• Gutenberg: Style Engine
• Block editor styles: initiatives and goals
• Style engine: functionality and design WordPress/gutenberg#42028

---

Maybe the simplest way to get started on this is to create a new repository with a minimum setup to bundle CSS/JS, test it on a static page and/or run it as its own plugin. When it's ready, it can be easily included as a module in the Framework.

How about we call it a Design System module, where we will eventually develop all the features for a "design system builder"?

[juliacanzani]

Thanks for the quick reply @eliot-akira, your proposed name and starting point sound good to me! I think a preview plugin similar to tangible-fields-example may provide an easier inroad for less technical team members. I wouldn't worry too much about Git and build steps being an obstacle, though. We've been encouraging all team members to familiarize themselves with these at least enough that they would be able to comfortably contribute to such a project (fair weather and no merge conflicts assumed).

It looks like you should already have access to that repo, but I've added you to another permissions group. Hopefully you can see it now!

[eliot-akira]

So, I prepared the foundation for a Design module.

https://github.com/TangibleInc/design

For now it just provides a minimal project setup, with commands to build CSS and see it on a local site; and a few ideas in the documentation to get started. When run as a standalone plugin, it adds an admin menu to show a test page with HTML5 elements.

We can continue discussion in that repository - I created issue TangibleInc/design-notes#1 to clarify what features the module aims to implement. I kept it as open-ended as possible to let you develop it as you'd like, and I can support the development with pull requests.

When the module is ready to be used by plugins, its newest changes can be pulled into the Framework.