I'm working on a small web application and I'm developing it using ReactJS and Material UI. In the examples provided in the documentation many components seems to have useStyles within the code. I followed the examples and now I basically a useStyles function within each of my components. My question is: is it good practice?
Usually I have a separate CSS file with all the classes, and frankly I find it easier to manage, but for this case I wanted to follow the CSS-in-JS pattern.
You can see an example of the code I'm working on here: https://github.com/sickdyd/foriio/blob/master/src/components/body/UserProfile.js
Thank you for any clarification you may can give me.
Yes, that is good practice.
It allows you to separate your concerns and localize your styles, where they are needed. You do not accidentally override styles while working on other classes. This will help you especially for larger projects.
It will also allow code splitting and only the CSS/CSS-in-JS that is needed and actually used will be downloaded and added to your website. This will improve your initial paint time as well since less CSS has to be parsed.
I you feel that you are repeating your code at several location, you could also share the useStyles functions or override the global theme to reduce the overall amount of code as well.
Related
I'm learning React.
It seems React highly promotes composition. Create React App even advises against reuse of css class.
Let's say I have a container, which is a white box, with nice rounded corner and shadow, etc. It can contain anything. That's it. No logic. Not much html except a <div>
Traditionally, I would just create a global css class named .white-box and then apply it to any <div> that I want it to be this white box.
I know in React you can do this, too. You can do whatever you want. But what is the general practice? From what I found online, it seems I should create a component for it and put any children inside:
<WhiteBox>
<div>anything</div>
</WhiteBox>
Isn't it overkill? What are the benefits of doing this? Should I create a component for everything that can be re-used, even when it is such a small thing?
This is honestly a matter of personal preference and experience.
For example, the seemingly pragmatic way would be to use a .white-box class on a div; it's super easy and requires no imports!
A bit later down the line, you decide that every white box inside some other control needs a bit more shadow, so you go and add a CSS rule for .some-component .white-box, and bam, now you got a shadow'ier white box without messing with the original CSS class. Nice and easy!
The problem with that is that when you do it once or twice, it's fine. But you'll soon develop a habit for "patching" the class name rules for specific purposes, and before you know it you're mixing rules without knowing it yourself, which is exactly what it says on the tin: Cascading Style Sheets.
I've been there myself, and it's no fun to maintain. Now I create components for everything, even things as simple as a white box. The trick is to name them right; you wouldn't call it WhiteBox because if you change the color of the box down the line, the rest of your code is a lie. ;) Instead, call it something like ContentBox; something that describes it's purpose, not what it looks like. Then use props to determine what characteristics the box should have:
<ContentBox shadow padded rounded>Awesome</ContentBox>
I'm personally a big fan of CSS Modules because they make sure that class rules never clash which avoids the issue outlined above entirely. Instead, if you want a class to inherit some styles from another, CSS Modules lets you compose them together.
Example CSS modules file:
.root {
background-color: #fff;
}
And a React component:
import React from 'react'
import styles from './ContentBox.css'
export default function ContentBox({ children }) {
return (
<div className={styles.root}>{children}</div>
)
}
The actual classname being used is actually something like ContentBox__root_abcd123random so even if you have another CSS file with the same .root class, the rules never clash.
An added bonus of doing it this way is that your components are now portable to other projects because it only depends on styling within the CSS file that ships with the component. I've enjoyed great reuse using this strategy across many internal web apps at our company.
That's right. It's not overkill when you are confident that features will be the same across your app. For example, you can have the nice shadow styles as you said, or guarantee that all containers have white background or might have a fluid prop which will expand the element for the whole parent width.
In fact, there are React frameworks like Semantic UI React that do exactly like this.
Every time you see yourself designing some HTML that should be consistent in your codebase, that should ring a bell for creating a single unique component for it. And if you think your components are big enough, maybe you should break them down.
This approach makes your code easy to test, once it's way more easier to test small stuff with limited and well-defined functionalities than a big component which several features. Once you glue them together, because of React one-way data flow approach, you know exactly why stuff is not working - you now have simple components for each feature, and if they are not working as expected, there is only one flow where data might have came.
As a beginner those concepts might be hard to grasp. But once you start digging into large codebases and projects, you will see how "modularizing" your application will have long-term benefits.
I'm working on a hybrid application for which I need a toolbar. This toolbar must handle different forms and functionalities, in some cases contains a title, other buttons and links and in others an autocomplete, then my questions is if is more efficient to build a dynamic component that accepts all these elements or work on different toolbar's that will be inserted and removed from the DOM as needed.
Thanks!
A dynamic toolbar will be faster, because angular wont need to re-render the whole toolbar each time it changes. It's smart enough just to find the stuff it needs to update.
Also it will make your code easier to maintain I think. Having multiple toolbars, probably with some shared logic/elements will cause repeated code.
Also you will probably have less lines of code with a dynamic toolbar, perhaps slightly reducing the size of your project. I suspect that wont be significant. Honestly, I think the biggest advantage wont be speed but cleaner, more maintainable code in general.
It depends on whether you are using lazy loading or bundling your entire App in one main.bundle.js
In the first case, you want to ship the strict minimum to the browser as it's needed. Therefore, you want separate component for each use case.
In the second case, it makes your app lighter to create on single component to handle different toolbar use cases.
To demonstrate this, (assuming you're not using lazy loading) you can create a small project with a main component which uses 2 different views.
In one case you create a single component for each view.
In the other you combine both views in one component.
Then build and serve both and you can see the difference in the weight of your JS files.
Hope this helps
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking to use something like Twitter's bootstrap to help me ease some of the pains of creating and working with some of the common design issues. However, I still fully intend to do a whole bunch of styling and stuff outside of their prepared stuff.
Would this be a bad idea? Potential conflicts down the road? Should I try to build on top of and use bootstrap as much as possible?
twitter bootstrap is great to get started and its exactly what it intends on helping developers. Instead of creating a lot of stuff from scratch, you got pretty much everything you need for a basic-to-medium frontend so you don't have to worry about it.
As you build your application, there will be times where you would need, for example, to replace the color of the buttons. So instead of having a .btn-primary be blue you want it pink.
you can override the .btn-primary in your own css, or even better, see how it behaves, copy the styles, change what you need and use your .pink-btn-primary.
Little by little your css would stop being twitter bootstrap and become your own variation, with the ability to rely on features being added to bootstrap with time.
Relying on bootstrap has a bit of a shortcoming - if a bug is fix or a new version changes its behavior (rare on css, but very possible on js) you will have to adjust to make sure you get the behavior that you want.
Also, You should be careful, as suggested, not to use their class names, and make sure you load your css files after bootstrap files.
good luck.
Bootstrap is meant to be used to build on top of and overwrite so you get the design you want.
As always, using Bootstrap depends on the project.
It makes starting out very easy but like most frameworks you don't always want to go against them, so you have to take them into consideration in the early stages of your design. Bootstrap relies heavily on wrapper elements and classes so using it for an existing website where the markup can't be changed won't work out for you.
Example: Their grid system works really well for their fluid container layouts but the default is 12 columns and you will want to look at all their customisation options to change this.. or see examples of using the .less pre-processor with Bootstrap and these settings apply a set margin that may not always work out for you, and you have to start thinking differently.. such as how you can nest elements to achieve the design you want, or start testing with new overwritten margin sizes.
You also need to consider any other frameworks you may be building on, e.g. ASP.NET MVC has a lot of built in features such as the client validation, and HTML helpers for form elements.. but they don't always allow you to apply wrapper elements and class names to them unless you first right your own extension of them.
Bootstrap has an Apache v2.0 license which says
irrevocable copyright license to reproduce, prepare Derivative Works
of
so as long as you keep the copyright license they allow you to change bootstrap as you see fit, obviously you shouldn't look to change what they have already extensively tested for you and you would rather just overwrite some things, but the option is always there.
I think most developers do not just use the prepared stuff, they always add some customization on top of it. As for CSS styling, You can keep the bootstrap.min.css file intact and write your custom css on another CSS file. If Bootstrap updates in future you can just replace that original bootstrap.min.css file and maybe have to make some minor adjustments.
I'm working on a large JavaScript-heavy app. Several pieces of JavaScript have some related CSS rules. Our current practice is for each JavaScript file to have an optional related CSS file, like so:
MyComponent.js // Adds CSS class "my-comp" to div
MyComponent.css // Defines .my-comp { color: green }
This way I know that all CSS related to MyComponent.js will be in MyComponent.css.
But the thing is, I all too often have very little CSS in those files. And all too often I feel that it's too much effort to create a whole file to just contain few lines of CSS - it would be easier to just hardcode the styles inside JavaScript. But this would be the path to the dark side...
Lately I've been thinking of embedding the CSS directly inside JavaScript - so it could still be extracted in the build process and merged into one large CSS file. This way I wouldn't have to create a new file for every little CSS-piece. Additionally when I move/rename/delete the JavaScript file I don't have to additionally move/rename/delete the CSS file.
But how to embed CSS inside JavaScript? In most other languages I would just use string, but JavaScript has some issues with multiline strings. The following looks IMHO quite ugly:
Page.addCSS("\
.my-comp > p {\
font-weight: bold;\
color: green;\
}\
");
What other practices have you for keeping your JavaScript and CSS in sync?
My perspective on CSS files is that they describe rules that define the theme of an application. Best practices generally state that content, presentation, and behavior should be kept separate so that it is relatively easy to change that theme. By having multiple CSS files, this becomes slightly more difficult, as a designer would have more files to deal with.
Additionally, CSS (Cascading StyleSheets) rules are affected by their position in the CSS document. By having multiple CSS files with different rules in each, it may become more difficult to prioritize which rules take precedence.
Finally, if you want to find out what CSS selector in your JS file matches what CSS file, try using a cool search tool, like grep, if you're on linux. If you're using a good IDE, you can also use it to quickly search for the rules, then you can just jump to the line number. I really see no advantage in keeping the CSS rules in different files; it will only complicate matters.
Additionally, I would advise against the idea of putting the CSS inline. By doing this, you will inevitably make it more difficult for your web designer to quickly and easily swap out the styles. The whole point of external CSS is so your web designer can change the theme or provide multiple themes for different users. If you embed the CSS in the JavaScript or HTML, you've then tightly coupled the content, behavior, and presentation.
Best practices generally suggest keeping content, behavior, and presentation separate for this very purpose.
Having one CSS file per JS file seems a good thing for me. It's clean, and easy to understand and to maintain. The only problem would be to have dozens of CSS files on every page, but I suppose you combine those files to one big file, so this problem does not exist in your case.
How to embed CSS in JavaScript? It depends on the environment you have, and how the build process is done. The easiest thing is to have a large comment at the beginning of every JavaScript file, something like this:
// <...>Your copyright notice here</...>
// <css>
/*
body{color:red;}
div{border:solid 10px lime;}
// ... other ugly styles.
*/
// </css>
Then during the build, you have to search for <css>...</css> blocks and extract the CSS by trimming the /* and */.
Of course, it creates a problem: if you are using an IDE with auto-completion, embedding CSS into a JavaScript file will make it impossible to use auto-completion in this case.
My preferred method is to keep all the CSS files separate and then have a build process that compiles them into a larger CSS file on deployment.
I would avoid merging your JS with your CSS. It may sound like a cleaner solution from the file-level, I think it'll get messy fast. That, and you'll lose the highlighting and syntax assistance your editor gives you.
Check out Csster. I wrote it to solve just this problem.
You embed your CSS rules directly in your Javascript, using Javascript object literal syntax. It's no uglier than raw CSS.
Csster.style({
h1: {
fontSize: 18,
color: 'red'
}
});
The rules are inserted into the DOM on the client side. This architecture simplifies your build process and reduces client requests.
You can use it like you describe, but Csster also provides a couple other niceties:
nesting to DRY up stylesheets
color functions like darken and saturate
built-in macros for common CSS idioms like clearfix, rounded corners, drop shadows.
extension points for custom behavior or cross-browser support
It's well tested and I've used it on quite a few projects. It is independent of jQuery, but plays well with it.
I'd love to have more people use it and provide feedback.
I've been asked to do the front end for a web app, and to use ExtJS specifically.
I've been working through a couple of tutorials, but I've not seen much variation on the default ExtJS look and feel except for some subtle changes to the colors and what not.
The design I've been handed seems to be a radical departure from the standard ExtJs look and feel. So before I head down a dead end or start chasing wild geese, I wondered wether any ExtJS experts out there could point out any potential pit falls in the design, or is everything do-able?
The design is here...
Definitely possible, IF you have pretty strong CSS skills and not afraid to customize the JS components to some extent. You're going to be overriding a lot of the default stylesheet content to get this look-and-feel, and for certain aspects it may require tweaking the markup generated by a component by default. If you are new to Ext JS this may be a bit daunting, but once you wrap your head around it you can do about anything you want.
Yes, it is definitely possible.
ExtJS is designed to be easily customised. With some CSS knowledge, you should not have problems getting that look and feel.
Just as an example, you may want to check out this service, which uses a very customized ExtJS skin:
Filespots - Find Out More
ExtJS Forum - Disussing Filespots
Filespots using ExtJS http://www.filespots.com/static/web/images/en/invite-users.jpg