> 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…
Rookie Vue dev here. I found Vue super easy to understand and to start using for my own simple stuff basically from day 1. Gradually as my tiny projects grew in complexity, I naturally started to feel the need to manage state better. And again, Vue docs led me gradually thru pure-Vue solutions towards VueX. It all felt very naturally, the documentation didn’t push me to anything, just gave me answers at my pace. Can’…
How we do Vue at GitLab: one year later
71–80 of 208 posts
Re: How we do Vue at GitLab: one year later
#72Earlier quoted context omitted.
HTML is for displaying information, not being littered with things js needs to query for and access. That's the whole point of using something like vue? Put a function on the vue component that will make a request, keep all the data stuff in vue.
While I largely agree, that's not really true... React for example wrecks your HTML with react related attributes on every DOM element. There is nothing wrong with storing some information in the DOM.
Except you're coupling your application state with the document model. If you ever do anything to change the DOM later on, (like installing React into your codebase) it'll come back to bite you in the ass hard, as now you need to find a means to communicate state that you just threw into the DOM like it were a slightly more acceptable global variable.
Re: How we do Vue at GitLab: one year later
#73Earlier quoted context omitted.
Funny thing is, Vue wihtout extras is more complex than React without extras.
Nope. Nope. Nope. Trainer here. I train in React and in Vue. My students do 3 times the work with raw vue than in raw react. Every one of them. All the time. It's not even on the same map.
Re: How we do Vue at GitLab: one year later
#74Earlier quoted context omitted.
I agree that single file components are awesome. I wish you had been introduced to styled components in react: 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 ) }
That really doesn't work well with: > Our designer could churn out neat html/css, but was a beginner in Javascript. I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete? That cod…
Yeah styled.div is a function as you can check out in the mdn docs I linked, it's really cool stuff.
Inheritance is done like:
const List = styled.ul`
li {
padding: 10px;
}
`
const HeavyPaddedList = styled(List)`
li {
padding: 20px;
}
`
If you wanted to just change the li you'd have to: const ListItem = styled.li`
padding: 10px;
`
const HeavilyPaddedListItem = styled(ListItem)`
padding: 20px;
`
You're writing scss within the text blocks. You're correct that you need some understanding of JS.I've never worked with designers that wrote css, I'd also probably not trust them to do so (my own failings).
I don't agree that it looks like an unholy mess (hyperbole may be lost on me), but I can see how it could be jarring at first look. I had a similar reaction when I looked at Relay (https://facebook.github.io/relay/), when they used literals for data fetching.
Re: How we do Vue at GitLab: one year later
#75Earlier quoted context omitted.
I agree that single file components are awesome. I wish you had been introduced to styled components in react: 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 ) }
God this is horrible. It's ugly. Hard to read. Things are scattered all over the code. And where is my sass ?
Re: How we do Vue at GitLab: one year later
#76Earlier quoted context omitted.
It looks like VueX supports async out of the box. That's a huge win IMO.
Is it? I thought Redux abstracting out the thunk layer was silly until that line of thinking lead to Redux-Saga. It actually seems to have been a pretty smart move.
Re: How we do Vue at GitLab: one year later
#77Earlier quoted context omitted.
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.
I'm a really big fan of the Ducks pattern where your action types are private to each reducer unless they're explicitly exported as an API. In my own code I don't even do that, instead exporting a function which operates on the state. https://github.com/erikras/ducks-modular-redux
You might still need to place actions/selectors in their own directory since they're not necessarily specific to any reducer. I believe this is how sagas are organized, though.
Re: How we do Vue at GitLab: one year later
#78Earlier quoted context omitted.
Nope. Nope. Nope. Trainer here. I train in React and in Vue. My students do 3 times the work with raw vue than in raw react. Every one of them. All the time. It's not even on the same map.
Even if you ignore 2-way-binding?
Starting with vue is just: add a script tag, put your template here, now your data here. Done.
The start up experience is nothing alike.
Re: How we do Vue at GitLab: one year later
#79At 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…
Same. That and the fact it took me an afternoon to get an hello world with react and understand it. And 20 minutes with Vue.
https://github.com/facebookincubator/create-react-app
npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start
Your sentiment is correct that tooling around these pieces of technology needs to always be first class. React failed miserably, and Vue did an AMAZING job.I'm probably starting to sound like a shill for React. I've used both and love both. I do like that React is "just javascript", which I think is why I use it.
Re: How we do Vue at GitLab: one year later
#80At 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…
Same. That and the fact it took me an afternoon to get an hello world with react and understand it. And 20 minutes with Vue.
I highly recommend watching Rich Hickey's "Simple Made Easy" [1] talk which covers how the right ("simple") choice may not be the "easiest" (convenient, most familiar) one.