Does anyone know if exists any official or most accepted reference for React naming conventions to use when we build our applications?
React has a lot of different type of components such as React.Component, directives, services and so on. Wouldn't you agree that having a reference naming convention when we implement them in our applications will make sense?
For example:
If we need to create new component how should we name them like [Something]Component or component[Something] or something else? And same applies for other classes.
Other things I wonder about is if variables/functions that belongs to the scope should have an special prefix or suffix. In some situations it may be useful to have a way to differentiate them from functions and other (none react code).
I'm a big fan of the airbnb React style guide.
https://github.com/airbnb/javascript/tree/master/react
They also have an overall JS style guide.
https://github.com/airbnb/javascript
My understanding is that the React team is un-opinionated when it comes to naming conventions.
With that said, it is also my understanding that components that return objects or classes traditionally start with capital letters and its how we differentiate from a component or other file that is not a class.
So if you see src/components/Header.js, you immediately know its a class-based component and if you see src/utils/validateEmails.js you know its going to be a function and not a class in there.
I would also warn about the airbnb style guide because I just took a look at it and they encourage the use of .jsx extensions, yet if you look at the Reactjs documentation: https://reactjs.org/docs/react-without-jsx.html they say that jsx is not a requirement when building with React, you can just use javascript all day long, so really one can infer that creating components with just a .js extension is satisfactory. What also backs up that inference is that the engineers at Facebook, the creators of React, do not recommend the utilization of .jsx and Dan Abramov says that using .jsx made a difference in the pre-Babel days, but now its not necessary, we can stick with .js extensions.
source: https://github.com/facebook/create-react-app/issues/87
Related
Almost all the references online mention the use of MDX with React.js. Even though other frameworks or libraries support MDX (with help of components), I haven't specifically seen the use of ".mdx" file formats outside of React.
The support of ".mdx" files in Gatsby and Next.js allows us to create a separate folder for the blog posts and have them stored anywhere (CMS, Github etc...) which helps in organizing. And the file extension of ".mdx" itself is pretty straight-forward and self-explanatory even for a beginner to grasp the concept.
So I was just wondering - If I would like to use mdx files, am I limited to React.js? Is it possible to use Svelte, Vue, Angular as well?
Yes you can use mdx outside of React but not everywhere, Check out this guides I hope they help!
mdx for Vue.js: https://mdxjs.com/guides/vue/
mdx for Svelte(MDsveX): https://madewithsvelte.com/mdsvex
MDX as such is specifically for React because it uses JSX to define it's component.
I am sure there are alternatives for other frameworks, as a Svelte user myself I know that at least Svelte has MDSVEX which is basically the same.
As I noticed, it seems create-react-app changed app.js class component based in a function component,
any idea why they did this?
React itself is moving away from class-based components.
A quotes from this doc: Introducing Hooks
In addition to making code reuse and code organization more difficult, we’ve found that classes can be a large barrier to learning React. You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers. Without unstable syntax proposals, the code is very verbose. People can understand props, state, and top-down data flow perfectly well but still struggle with classes. The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers.
Additionally, React has been out for about five years, and we want to make sure it stays relevant in the next five years. As Svelte, Angular, Glimmer, and others show, ahead-of-time compilation of components has a lot of future potential. Especially if it’s not limited to templates. Recently, we’ve been experimenting with component folding using Prepack, and we’ve seen promising early results. However, we found that class components can encourage unintentional patterns that make these optimizations fall back to a slower path. Classes present issues for today’s tools, too. For example, classes don’t minify very well, and they make hot reloading flaky and unreliable. We want to present an API that makes it more likely for code to stay on the optimizable path.
To solve these problems, Hooks let you use more of React’s features without classes. Conceptually, React components have always been closer to functions. Hooks embrace functions, but without sacrificing the practical spirit of React. Hooks provide access to imperative escape hatches and don’t require you to learn complex functional or reactive programming techniques.
Now that React finally has hooks, will this eventually be the new standard for creating components or will the need to create class components still exist?
I understand that at the moment hooks can not accomplish everything a class can. Such as, providing hooks to lifecycle methods for getSnapshotBeforeUpdate and componentDidCatch. However, the React team has said they plan on adding this functionality soon. They also mention that there are no plans to remove classes from React.
So when all lifecycle methods are supported is there any reason to create class components? Do classes still handle certain situations better than a functional component at this point?
I'm going to politely disagree with the comments above. Hooks are 100% the future of React. I'd highly recommend reading the Medium article that Dan Abramov wrote in October 2018. There is also a video at the top of the article of Dan Abramov delivering the keynote address at the last React Conf. In his address he introduces hooks for the first time. He adds towards the end of address that he does not recommend refactoring your old components immediately, but he does recommend using hooks moving forward (and this is when hooks were still an alpha release):
I ask you not to rewrite your whole apps in hooks...because personally I find that it takes a bit of a mind shift to start thinking in hooks, and it might be a bit confusing if you just try to take a class Component and convert it, but I do encourage you to try using hooks in some of the newer code that you're writing and let us know what you think.
He follows that with:
So, in our view hooks represent our vision of the future of React. But, they also represent the way we move React forward, and that is that we don't do big re-writes. And, that is that we want the new patterns that we like better to co-exist with the old patterns.
He discusses this in greater detail if you watch the whole thing. I believe the take away from this is that Facebook and Dan Abramov see hooks as the future of React (so do I, but my opinion doesn't matter). They see the patterns that emerge from hooks as significantly better than the patterns established by class Components. They also indicate that the reason they intend to maintain class Components is because they don't intend to re-write React or introduce breaking changes.
There is also less code bloat due to the use of stateful functions as opposed to extending classes. Hooks hook directly into the global application state maintained by the React framework, as opposed to maintaining it locally through an abstraction (which is why they're called hooks). Hooks promote code re-usability through custom hooks. Hooks allow us to monitor individual state without lifecycle methods and conditionals through useEffect. There are plenty of other benefits to using hooks over class Components, but I don't want to write a book here.
In addition to the benefits listed, and the praise from the Facebook team, I'd point to all of the third-party libraries that are adding support for hooks. The FAQ page you shared indicates that both Redux and React Router are planning on releasing support for hooks. In fact, the Redux maintainers have been excitedly discussing hooks since they were introduced to the public. And, Ryan Florence (the creator of React Router) spoke after Dan Abrimov at React Conf. He actually gave a greater endorsement for hooks:
Dan just said "don't re-write your apps in hooks". I think you should.
In addition to those, Material-UI version 4-alpha is out, and they have introduced hooks as well.
In summary, hooks are the future of React, and we should be using them. They are in stable release since React v16.8.0, and there is no reason not to predominantly use them moving forward.
We are preparing to migrate our React codebase to use ES6 classes, and of course that means dealing with all of our mixins that we have. I've explored the documentation that discusses ways of converting mixins such as using Higher order components or taking utility methods and putting them in imported modules. However, we have some mixins for which these methods will not work.
One simple example is a mixin that contains a version of the handleChange function from this forms doc: https://facebook.github.io/react/docs/forms.html
It's a kind of utility function but since it interacts with state, it can't be placed in a separate module. It won't work as an HOC because then the nested component won't have access to the function.
It seems a good case for using inheritance but I keep reading about how that is discouraged and how it is unnecessary in React. I've also seen "mixin" patterns for ES6 that involve functions that return a subclass that adds functionality to another class, effectively dynamically subclassing something, but something about that doesn't seem right and it seems to miss the point about why mixins have fallen out of favor.
I suppose the code from the mixin can just be inlined into the components that use it but I hate having boilerplate code like that replicated everywhere. Plus, we have other mixins with the same concerns that contain more complex functionality which makes that even more problematic.
I'd love to hear people's suggestions for how best to handle this issue within best practice guidelines of react and ES6. Thanks!
I'm pretty new to development. Right now working on an webapp in my freetime.
Backend will be written in Python (here I have the best experience).
How good is the Idea to mixing React components:
like: https://github.com/brillout/awesome-react-components
My Idea was to use these components or let others create components for me (for example a slide show or whatever)
The question is, is this a good Idea? I'm worry that this might create a lot of overhead. For example one component is based on bootstrap and the other on foundation (As I said I'm not experienced web developer and can't judge if this can actualy really happen).
Thanks!
The idea of React components is to have the smallest piece of code you can define.
However, mixing different CSS frameworks, like Bootstrap or Foundation doesn't sound like the best idea. You can, of course mix ready-made components (like React-Bootstrap) with your own custom components, but ideally you would choose one framework and stick with it.
The good thing about React is that you can possibly switch between Frameworks without the need of refactoring everything.
Let's say, for instance, you have a custom component called Slider. If you later decide to use MaterialUI, depending on your configurations, you could just change the import from import Slider from "./Slider" to import Slider from "material-ui/Slider" and the rest of your code would be untouched.
Pick a CSS / UI framework and stick with it. These days I have been working with Semantic UI and they have good integration with React via http://react.semantic-ui.com/
It is awesome! :)
And in addition to that, you can also build your own custom components.
If you think adding a whole framework to your project is a lot of burden, then you can make everything your own from scratch. (Either (1) using the CSS framework classes for the components or (2) defining your own CSS classes)
And to conclude I also agree to not mix CSS frameworks as there might be conflicts! It's not fun! In my project, Bootstrap was conflicting with Semantic UI, so I just stuck with the latter.