-
Notifications
You must be signed in to change notification settings - Fork 117
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
base: master
Are you sure you want to change the base?
Conversation
Thanks for the pull request, @dcoa! What's next?Please work through the following steps to get your changes ready for engineering review: 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Update the status of your PRYour PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate. 🔘 Let us know that your PR is ready for review:Who will review my changes?This repository is currently maintained by Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:
When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for putting this together! This is looking wonderful! I left a few comments with questions, more about possible ways to streamline the process than the documentation itself.
|
||
|
||
From version 23 `Paragon <https://www.notion.so/Write-the-brand-docs-7a60ece8489e40e1a6ca6ac4b79aac82?pvs=21>`_ supports CSS variables and | ||
`design tokens <https://tr.designtokens.org/format/#abstract>`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`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. | ||
|
||
.. code-block:: | ||
|
||
. | ||
└── tokens/ | ||
└── src/ | ||
├── core/ | ||
│ └── <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 |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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. |
There was a problem hiding this comment.
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
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: | ||
|
||
.. 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. |
There was a problem hiding this comment.
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.
#. Install Paragon | ||
|
||
.. code-block:: bash | ||
|
||
npm install paragon |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be updated in paragon as well https://github.com/openedx/paragon/tree/alpha?tab=readme-ov-file#theming-with-design-tokens
} | ||
} | ||
|
||
Replace the destination with the desired path and run the command, it is recommended to use ``./dist/``. |
There was a problem hiding this comment.
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/
?
There was a problem hiding this comment.
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
|
||
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: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
Hi @dcoa! Just checking in on this! |
Hi, @mphilbrick211 this is a work in progress I will allocate some time in the following weeks to finish it. Sorry for that. |
=================================== | ||
|
||
|
||
From version 23 `Paragon <https://www.notion.so/Write-the-brand-docs-7a60ece8489e40e1a6ca6ac4b79aac82?pvs=21>`_ supports CSS variables and |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Paragon Documentation, yes
. | ||
└── tokens/ | ||
└── src/ | ||
├── core/ |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
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. | ||
|
||
.. code-block:: | ||
|
||
. | ||
└── tokens/ | ||
└── src/ | ||
├── core/ | ||
│ └── <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 |
There was a problem hiding this comment.
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
|
||
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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
041a6c2
to
47b7209
Compare
47b7209
to
719dec8
Compare
This PR adds a how-to about design tokens support for the brand package.
There are still details to evaluate such as whether should we install Paragon as a dev dependency and the possible creation of a Paragon CLI command specific to this package.
Any early feedback should be great @brian-smith-tcril and @PKulkoRaccoonGang.