-
Notifications
You must be signed in to change notification settings - Fork 293
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
Less opinionated styling branch? #80
Comments
Hi, @mininternet. Thank you for the feedback. It would be very hard to maintain a branch with other styling library with all ARc components included. However, they are just examples. Setting up a SCSS environment to be used on a clean src folder should not be hard. Tell me what you think. I would like to help you, @gururajjeerge or anyone willing to work on that. :) |
I actually do like the Atomic design, so want to keep that in my project, and not go off the clean src. It's possible that my issue was with the React Toolbox (http://react-toolbox.com/#/) library itself - there is an issue with its react-css-themr dependency. I was able to add CSS and SASS loaders to webpack, and now have the boilerplate working with Material -UI (http://www.material-ui.com/), so will proceed with that library for now. (Although i was unfortunately unable to get React Semantic UI http://react.semantic-ui.com/ to work...) Thanks again for the assistance and suggestions. |
@mininternet Style engine is great part of any component and it's better to stick with one for better performance and maintaining. |
@kybarg - I haven't found benchmarks that say inline (javascript) CSS is more performant than SASS/CSS, in fact i've read, and personally experienced with JSS and Radium, the opposite. Is also (IMO) a slower method to develop against, since you constantly need to toggle between browser and code editor, whereas with SASS you can map file workspaces directly in your browser, and leverage source maps for live styling/editing. However, if you mean that applying styles per component (co-location) is more performant, then i completely agree, which is why i'm importing .scss files at the component level, not globally (dependency injection). This is an excellent boilerplate, but it seems to me that it's a bit blurred between being a starter kit AND a custom component library, which is overly ambitious IMHO, considering several sophisticated libraries already exist: http://dev.office.com/fabric#/components I understand the push for inline CSS in the webdev world, primarily triggered in 2015 by the creator of Radium, but he has since updated his philosophy, in this speaker deck, which i think is worth a read - https://speakerdeck.com/alexlande/components-a-styling-odyssey Again, just my two cents. I'm far along with a highly visible project, using Arc as the boilerplate, but I've had several issues integrating external component libraries unfortunately. |
The intent of ARc components is to serve, just like the whole project, as a boilerplate for us to create a new component. This is not a component library (may be in the future, but all components must be heavily tested in production first). The recommended workflow is to use the Using external component libraries should not be a pain. If this is the case, please let's focus the discussion on what we can do on the boilerplate to make it easier. |
@mininternet - would you mind sharing what steps you had to take, perhaps even a patch or a repo, to get the Material UI component library working? I was actually surprised this was an issue, I thought that all CSS was part of the components themselves in Material-UI: Your experience can save a lot of time for future users of this boilerplate :) |
I basically just had to install sass-loader, css-loader, and style-loader, and configure webpack to use these loaders. Material UI assumes these loaders are present. (Though my project is based on Arc with webpack v1, haven't had a chance to upgrade to webpack v2 yet.) |
Great boilerplate!
However, I've been unable to get it working with React Toolbox, due to a conflict it would appear with styled components.
Since most component libraries still use SASS, has there been any consideration of having a branch with SASS included, for easier external component integration, rather than having to write all components manually?
(I've also experienced issues using inline CSS with Radium/JSS, though I understand the reasoning behind the concept)
The text was updated successfully, but these errors were encountered: