Live data from Hacker News

How we do Vue at GitLab: one year later

about.gitlab.com

71–80 of 208 posts

Re: How we do Vue at GitLab: one year later

#71
post #3

> 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 are you learning Vue? Looking to expand my toolkit.

Re: How we do Vue at GitLab: one year later

#72
post #6

Earlier 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.

>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

#73
post #12

Earlier 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.

Even if you ignore 2-way-binding?

Re: How we do Vue at GitLab: one year later

#74
post #57

Earlier 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…

Interesting critique. I would highly suggest checking out template literals: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#75

Earlier 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 ?

It doesn't support sass, but it does support scss.

Re: How we do Vue at GitLab: one year later

#76
post #22
post #19

Earlier 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.

There's vuex-saga as well. Something built in would have been nice because even though sagas are cool, the learning curve is steep enough for me to avoid it in projects.

Re: How we do Vue at GitLab: one year later

#77
post #50

Earlier 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

Hm, interesting. I like it. I'm also curious about how selectors come into play here as well (exported getter functions for shielding app from reducer state shape).

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

#78
post #73

Earlier 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?

The whole component russian dolls with data/callback passing is something most beginers have a very hard time to grasp. Add webpack to the mix, make them fight with JSX that doesn't want to do what they need and voila, you get a sad student.

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

#79
post #30

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…

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 implore you to checkout create-react-app to get a hello world really quick:

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

#80
post #30

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…

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.

20 minutes vs an afternoon is probably not a great gauge for making technology choices.

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.

[1] https://www.infoq.com/presentations/Simple-Made-Easy

Post reply on HN