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

docs: create how to work with design tokens #26

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
151 changes: 151 additions & 0 deletions docs/how-to/design-tokens-support.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,151 @@
===================================
Paragon Design Tokens Compatibility
===================================


From version 23 `Paragon <https://www.notion.so/Write-the-brand-docs-7a60ece8489e40e1a6ca6ac4b79aac82?pvs=21>`_ supports CSS variables and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[question]: Will there be a link here to the future npm Paragon 23 page?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Paragon Documentation, yes

`design tokens <https://tr.designtokens.org/format/#abstract>`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`design tokens <https://tr.designtokens.org/format/#abstract>`.
`design tokens <https://tr.designtokens.org/format/#abstract>`_.


How to structure the brand design tokens
========================================

The file structure in the brand package should be the same as the version of Paragon used as a reference to allow the merge/override during the build time.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be nice to link to and/or provide a URL format for the paragon tokens directory from here

https://github.com/openedx/paragon/tree/v23.0.0-alpha.3/tokens currently works to show the directory for the v23.0.0-alpha.3 tag, so maybe having something like

To see the tokens directory structure for the version of Paragon you are targeting you can navigate to https://github.com/openedx/paragon/tree/TARGET_PARAGON_VERSION/tokens. For example, if you were targeting Paragon v23.0.0 you would navigate to https://github.com/openedx/paragon/tree/v23.0.0/tokens.

could work


.. code-block::

.
└── tokens/
└── src/
├── core/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[question]: Is it worth specifying here more precisely which directories may be needed? For example, now in the alpha version of Paragon we have semantic tokens that we divide into core, alias and global tokens? More information on semantic design tokens

Copy link
Author

@dcoa dcoa Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think due to the the how-to is explaining how to work with the paragon design tokens version I think a mention and a link to that explanation about semantic tokens is a valuable addition. I don't want to duplicate the information if it is already in Paragon. As well, I think the user should decide the folders that they want to include I mean if I want to change a token in the component folder worth it add the global and aliases as well?

│ └── <name_of_the_folder>/
│ └── <name_of_the_file>.json
└── themes/
├── light/
│ └── <name_of_the_folder>/
│ └── <name_of_the_file>.json
├── dark/
│ └── <name_of_the_folder>/
│ └── <name_of_the_file>.json
└── my-theme/
└── <name_of_the_folder>/
└── <name_of_the_file>.json

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Open question here: the current structure of this repo has paragon as a directory at the top level. Is the plan to have tokens as a directory at the top level, or is the plan to have paragon/tokens?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. Perhaps consumers can have their own system design and their own set of token designs. It would be nice to have such a named structure for tokens provided by Paragon

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understanding that the brand package contains more than only paragon related code and the guide is related to how to use it with the paragon design system makes sense to have the tokens into the paragon folder.



Once you have identified the token to override, you can replace ``<name_of_the_folder>`` and ``<name_of_the_file>`` with the right names.

In terms of tokens, Paragon follows the specifications of the `Design Tokens Community Group <https://tr.designtokens.org/format/#abstract>`_.

The structure that follows to define most of the tokens is ``category > item > subitem > property > state``, for example:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be a good idea to add an image from the documentation site here
How do you like my proposal?

image


.. code-block:: json

{
"spacing": { // Category
"$type": "dimension",
"annotation": { // Item
"padding": { // Property
"$value": ".5rem",
"$source": "$annotation-padding"
},
"arrow-side": { // Subitem
"margin": { // Property
"$value": "{spacing.annotation.padding},
"$source": "$annotation-arrow-side-margin"
}
}
}
},
"typography": {
"annotation": {
"font-size": {
"source": "$annotation-font-size",
"$value": "{typography.font.size.sm}",
"$type": "dimension"
},
}
},
}

Each token has specific attributes:

- **Value**: It is the value that will be assigned to the variable, which could be a value or a reference, such as l arrow-side in the above example.
- **Type**: Indicates the property to be processed (color, dimension, etc..). This value could be defined for the token itself or a group of tokens (e.g. spacing)
- **Source**: This value is additional and indicates the equivalent in saas notation.
- **Modify**: Optional value that helps to apply a specific token modification.

Use the ``source`` attribute to map the tokens in Paragon and create the theme files. Also, it will help you to replace the values in scss files if you have custom variables (see below).

You can check `Paragon tokens <https://github.com/openedx/paragon/tree/alpha/tokens>` to know the folder and token structure, and how to work with modifiers.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part feels like it could go under a separate heading. That way we'd have a section for where to put files and how to name them, and a section for what to put in those files.



Build the tokens and generate the CSS variables
===============================================

To build the tokens you can use Paragon CLI.

#. Install Paragon

.. code-block:: bash

npm install paragon

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it makes sense to add Paragon as a dev dependency for this repo instead of instructing people to install it. Then we could just have people run npm ci and people wouldn't end up with changes to their package.json and package-lock.json files.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


#. Once the tokens have been created. Go to the ``package.json``, there is a script template:

.. code-block:: json

{
"scripts": {
"build-tokens": "paragon build-tokens --source ./tokens/ --build-dir <destination_path>"
}
}

Replace the destination with the desired path and run the command, it is recommended to use ``./dist/``.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a specific reason to have this as a template instead of just hardcoding ./dist/?

Copy link
Author

@dcoa dcoa Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

highlight and in any case be use in the package.json file as the destination for the script template

You can check the CLI options `here <https://openedx.atlassian.net/wiki/spaces/BPL/pages/3770744958/Migrating+MFEs+to+Paragon+design+tokens+and+CSS+variables#Paragon-CLI-Documentation>`_

.. code-block:: bash

npm run build-tokens

#. Publish the package.

#. Once it is installed in the application use the Paragon CLI with the ``replace-variables`` command to use your custom tokens.


The ``theme-urls.json`` file
=============================

It is recommended to create the `theme-urls.json` if you are working with runtime theming and want to use ``ParagonWebpackPlugin`` to preload the token URLs during the application build time.

The file must be in the ``dist`` folder and should have:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the biggest fan of having people directly create/edit files in the dist directory. It'd be great to be able to .gitignore dist and have this file copied in as part of the build process.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think could live in the paragon/tokens folder, referencing all the desired variants. May be in this way, we will need to be clear about the relative path (understanding that the design tokens destination path is not necessary the dist folder, it is the ideal but is not limited to it)


.. code-block:: json

{
"themeUrls": {
"defaults": {
"light": "light"
},
"variants": {
"light": {
"paths": {
"default": "./light.css",
"minified": "./light.min.css"
}
}
"my-theme": {
"paths": {
"default": "./my-theme.css",
"minified": "./my-theme.min.css"
}
}
},
"core": {
"paths": {
"default": "./core.css",
"minified": "./core.min.css"
}
}
}
}

The paths must be relative to the ``theme-urls.json``file and contain all the variants that you want to use preload.
3 changes: 3 additions & 0 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,9 @@
"name": "@openedx/brand-openedx",
"version": "1.0.0-semantically-released",
"description": "The default branding and SASS theme package containing for Open edX applications. This package is designed to be copied and customized.",
"scripts":{
"build-tokens": "paragon build-tokens --source ./tokens/ --build-dir <destination_path>"
},
"repository": {
"type": "git",
"url": "git+https://github.com/openedx/brand-openedx.git"
Expand Down