Thanks! We're porting their grid system manually at the moment, the foundations don't really change much and we're quite selective about what's being ported.
We're actually experimenting with deprecating access to classes (i.e exposing components rather than class names as the public API) - will be interesting to see how popular that approach is.
2. LESS has been our favourite pre-processor for a white but we're finding it doesn't play well with packaging modular components on npm. Some real limitations around the @import logic, and the core team refuse to make it to work with node-style require path resolution which is disappointing.
From here I think it's more likely we go with the "styles in components" approach (via Radium or similar) and make variables / themeing available via context. Much easier to package & use "out of the box". Might keep a "base" css include though, or possibly use the Bootstrap 4 "Reboot". The distinction between, and best way to package, component styles and page styles is something we're putting a lot of thought into!
We're actually experimenting with deprecating access to classes (i.e exposing components rather than class names as the public API) - will be interesting to see how popular that approach is.
2. LESS has been our favourite pre-processor for a white but we're finding it doesn't play well with packaging modular components on npm. Some real limitations around the @import logic, and the core team refuse to make it to work with node-style require path resolution which is disappointing.
From here I think it's more likely we go with the "styles in components" approach (via Radium or similar) and make variables / themeing available via context. Much easier to package & use "out of the box". Might keep a "base" css include though, or possibly use the Bootstrap 4 "Reboot". The distinction between, and best way to package, component styles and page styles is something we're putting a lot of thought into!