@infonomic/uikit 6.0.0 → 6.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +12 -3
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -10,11 +10,11 @@ It just doesn't belong in UI kits and libraries.
|
|
|
10
10
|
|
|
11
11
|
## Rationale
|
|
12
12
|
|
|
13
|
-
In addition to our thoughts above, this kit is built around the philosophy of adopting or 'folding in' best-in-class components, like the ones in well-known 'à la carte' headless component libraries such as [Base UI](https://base-ui.com/),
|
|
13
|
+
In addition to our thoughts above, this kit is built around the philosophy of adopting or 'folding in' best-in-class components, like the ones in well-known 'à la carte' headless component libraries such as [Base UI](https://base-ui.com/), and [React Aria](https://react-spectrum.adobe.com/react-aria/index.html) as well as individually well-known components such as [React Day Picker](https://github.com/gpbl/react-day-picker) and more.
|
|
14
14
|
|
|
15
15
|
Having lived through a full generation of 'all-in-one' and difficult to override themed UI kits like Bootstrap and Material UI, the trend towards composable headless (unstyled) component libraries is a welcome one - and one that forms the basis of this kit.
|
|
16
16
|
|
|
17
|
-
Many of the current components are
|
|
17
|
+
Many of the current components are built on Base UI. The great thing about wrapping these components in a client-consumable interface and library, is that in theory at least, the consumer of our kit's components won't have to worry about implementation details, or migration from Base UI to another underlying component library. The 'contract' and core styling semantics will never change.
|
|
18
18
|
|
|
19
19
|
## Design Goals
|
|
20
20
|
|
|
@@ -36,7 +36,7 @@ For components - this means ensuring that the layer specificity order appears at
|
|
|
36
36
|
|
|
37
37
|
The use of CSS modules will also allow us to support exporting individual components separately (we export a single bundle for import at the moment) helping to reduce the import and bundle size of the consuming client. Once we've enabled single component exports, a client will then be able to import the main style.css file followed by an individual component. We'll be revisiting this soon.
|
|
38
38
|
|
|
39
|
-
Lastly - we highly value the option to 'tell' components to ignore or override a top-level theme decision of light or dark. There is an intentionally duplicated `.not-dark` class selector in our tokens
|
|
39
|
+
Lastly - we highly value the option to 'tell' components to ignore or override a top-level theme decision of light or dark. There is an intentionally duplicated `.not-dark` class selector in our functional tokens file. Being able to use `.not-dark` means that we can override components that need to be in 'dark mode' on an otherwise 'light theme', or that need to be in .not-dark mode, on an otherwise 'dark theme'.
|
|
40
40
|
|
|
41
41
|
## Getting Started
|
|
42
42
|
|
|
@@ -119,6 +119,15 @@ Here's an example Tailwind CSS integration. Note that we have our own reset, and
|
|
|
119
119
|
'Source Code Pro', ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas,
|
|
120
120
|
'Liberation Mono', 'Courier New', monospace;
|
|
121
121
|
|
|
122
|
+
--color-primary: var(--primary);
|
|
123
|
+
--color-secondary: var(--secondary);
|
|
124
|
+
--color-accent: var(--accent);
|
|
125
|
+
--color-noeffect: var(--noeffect);
|
|
126
|
+
--color-success: var(--success);
|
|
127
|
+
--color-info: var(--info);
|
|
128
|
+
--color-warning: var(--warning);
|
|
129
|
+
--color-danger: var(--danger);
|
|
130
|
+
|
|
122
131
|
--color-theme-25: var(--theme-25);
|
|
123
132
|
--color-theme-50: var(--theme-50);
|
|
124
133
|
--color-theme-100: var(--theme-100);
|
package/package.json
CHANGED