41–50 of 208 posts
Earlier quoted context omitted.
Then it's an unfair comparison. Vue does state management out of the box. React really doesn't. Yeah, it has setState, but that's nothing compared to Vue.
I'm very skeptical of that assertion. Can you provide an example of something Vue provides that React does not?
At my last job we did a comparison between Vue and React before rewriting a major frontend application. We did a POC in both React/Vue and ended up using Vue mainly due to the following reasons: Single File Components Single file components (.vue files) is the best thing about Vue. I understand this might be a personal preference, but we wanted to avoid CSS-IN-JS. Our designer could churn out neat html/css, but was a…
import styled from 'styled-components'
const Container = styled.div`
padding: 10px;
background: ${
({ isHovered }) => isHovered ?
'green' :
'red'
};
`
const H1 = styled.h1`
font-size: 15px;
`
const P = styled.p`
font-size: 10px;
`
const MyComponent = ({ isHovered }) => {
return (
Hello
This is a thing
)
}Earlier quoted context omitted.
I'm a Redux maintainer, and I spend most of my free time answering questions about React and Redux. Yes, since probably early 2016, many tutorials have basically said "you need to learn React and Redux together", and that's the message that a lot of junior devs have been taught. However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then yo…
However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation. That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together. Put yourself in the shoes of a CTO at a new star…
Okay, how big is our web application? A few pages with a form? We'll avoid Redux for now. We might even avoid React.
It's like anything else: should you set up a Spark cluster if you're only processing Gb's of data? Probably not, but you might need it some day -- so make your best guess.
Earlier quoted context omitted.
I'm a Redux maintainer, and I spend most of my free time answering questions about React and Redux. Yes, since probably early 2016, many tutorials have basically said "you need to learn React and Redux together", and that's the message that a lot of junior devs have been taught. However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then yo…
However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation. That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together. Put yourself in the shoes of a CTO at a new star…
Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux.
Then, build something small. Learn Vue. Repeat.
Now you understand both options enough to make an educated decision. Feel confident building your big, gotta-get-it-right-off-the-bat startup project in whatever works best for you.
> We discovered that VueX makes our lives easier. If you are writing a medium to large feature, use VueX. If it's a tiny feature, you might get away without it. I feel like this is Vue starting to get the React treatment. React was (and still is!) a very simple library until people realized they needed to do fancy things to make complex applications manageable. Redux came out, everyone fell in love with it, and React…
What Vue can do is create a well-designed state management library that works out of the box without umpteen lines of boilerplate... and that's exactly VueX. If you love to type, though, I highly recommend Redux! const ADD_TODO = 'ADD_TODO' import { ADD_TODO } from '../actionTypes' function addTodo(text) { return { type: ADD_TODO, text } } dispatch(addTodo(text))
Earlier quoted context omitted.
While I personally avoided this pitfall and learnt React alone before Redux, I have not meet anyone else who did the same. Literally everyone I've talked to about learning React did so (or tried, and failed to do so) with both, up front.
Wow, I wonder where people are getting the idea that they need to learn Redux. If you start a new job at a company that uses React, then you probably need to learn React + Redux simultaneously. But if you're just picking up React, Redux isn't useful whatsoever. This image, from React conf years ago, communicates this sentiment perfectly: https://i.stack.imgur.com/tnk9a.png
Because everyone with a React job or substantial React project uses Redux (or a similar library). It is common for junior devs to rush through learning libraries in hopes of being employable or a "real developer" as soon as possible.
Earlier quoted context omitted.
However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation. That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together. Put yourself in the shoes of a CTO at a new star…
If you're the CTO of a new startup, don't pick a technology to build your startup in without building something with that technology first. Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux. Then, build something small. Learn Vue. Repeat. Now you understand both options enough to make an educated decision. Feel confident…
Theoretically, you can get by without learning it. In practice, the moment you try to build a real company, you need it. That necessitates learning Redux.
I think this is an uncomfortable thought because it implies that Vue is way easier for devs to get into, and that's step one to displacing React+Redux. But that seems like an uncomfortable truth.
Whoever is in charge of React needs to give Vue the Snapchat treatment. Take them seriously as competitors. There's still time.
> We discovered that VueX makes our lives easier. If you are writing a medium to large feature, use VueX. If it's a tiny feature, you might get away without it. I feel like this is Vue starting to get the React treatment. React was (and still is!) a very simple library until people realized they needed to do fancy things to make complex applications manageable. Redux came out, everyone fell in love with it, and React…
However, I would argue that is not ok in that it should never be necessary and it's use would be a code smell to me and indicate that the code in question is likely not using Vue properly.
I suspect it would be more valuable in the long term to ask people to take more time and learn to use Vue instead of jQuery to solve the problem at hand.
Edit: I should note that Gitlab came to the same conclusion and I misread their comments on it as accepting the argument that it would be ok for querying the DOM. What the article says:
> At first I had several discussions about using jQuery with Vue. Some had said it might be OK, but only in read-only (querying) situations. However, after doing the research, we found that it is not a good idea to use jQuery with Vue. There will always be a better solution. We found that if you ever find yourself needing to query to DOM within a Vue architecture, then you are doing something wrong.
This I completely agree with.
Earlier quoted context omitted.
What Vue can do is create a well-designed state management library that works out of the box without umpteen lines of boilerplate... and that's exactly VueX. If you love to type, though, I highly recommend Redux! const ADD_TODO = 'ADD_TODO' import { ADD_TODO } from '../actionTypes' function addTodo(text) { return { type: ADD_TODO, text } } dispatch(addTodo(text))
To be fair, you don't really need to declare your constants elsewhere. This is just a pattern people stuck with, because they're stubborn about constants, I think. Doing a find/replace is so incredibly easy that it's kind of silly to add a bunch more boilerplate to protect against one DRY quip.