Using an asset loader is much easier for these types of resources as it allows us to export in bulk and receive the updates for free provided design team uses the same names as before.
Each category here has some different categorization used internally, e.g size or color etc.
Currently in the codebase there is three asset loaders which all use very similar macros.
src/quo/components/icons/icons.clj
src/quo/components/utilities/social/loader.clj
src/quo/components/utilities/token/loader.clj
Acceptance Criteria:
Refactor these macros and their corresponding components etc to make these pieces of code easier to maintain and add future loaders with. It's likely there is more going to be added by looking at that file.
move icons to utilities folder 👍
additionally consider adding a unit test or a component spec to the outer (view) component if it helps stabilise the api etc 👍
J-Son89
commented
8 months ago
There are many asset loaders used in the codebase. These are mostly for files related to: https://www.figma.com/file/qLLuMLfpGxK9OfpIavwsmK/Iconset?node-id=3239%3A5849&mode=dev
Using an asset loader is much easier for these types of resources as it allows us to export in bulk and receive the updates for free provided design team uses the same names as before.
Each category here has some different categorization used internally, e.g size or color etc.
Currently in the codebase there is three asset loaders which all use very similar macros. src/quo/components/icons/icons.clj src/quo/components/utilities/social/loader.clj src/quo/components/utilities/token/loader.clj
Acceptance Criteria:
Refactor these macros and their corresponding components etc to make these pieces of code easier to maintain and add future loaders with. It's likely there is more going to be added by looking at that file.
move icons to utilities folder 👍
additionally consider adding a unit test or a component spec to the outer (view) component if it helps stabilise the api etc 👍