Live data from Hacker News

How we do Vue at GitLab: one year later

about.gitlab.com

21–30 of 208 posts

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

#21
post #2

Why is GitLab putting data into their html? "You can pass your endpoints in through the data attributes." Why store endpoints and other js related data on a DOM element. This sounds like a left over paradigm they kept from their jQuery mindset, or am I mistaken?

I don't know GitLab's exact motivations although I noticed the same thing. I suspect it might be because they're using Vue components on already existing Server Rendered pages as opposed to a full SPA, so by passing the endpoint in the template they can allow the actual URL for that page to be set in the controller, maintaining cohesiveness.

E.g. on the server-side .html.erb they'd have something like

`...`

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

#22
post #19

Earlier quoted context omitted.

It's not, it's literally the same (they said VueX is based on Redux). The difference is React.

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

#23
post #12
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…

Funny thing is, Vue wihtout extras is more complex than React without extras.

no, it's actually quite the opposite. vue took all the complexities out of react/redux it's not even funny.

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

#24
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.

This is not the same as what gitlab is doing. React had attributes in order to remount correctly on the client side after a server render, this was removed. Using the latest react versions have nothing on the dom that isn't specifically needed to render correctly.

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

#25
post #2

Why is GitLab putting data into their html? "You can pass your endpoints in through the data attributes." Why store endpoints and other js related data on a DOM element. This sounds like a left over paradigm they kept from their jQuery mindset, or am I mistaken?

I don't know GitLab's exact motivations although I noticed the same thing. I suspect it might be because they're using Vue components on already existing Server Rendered pages as opposed to a full SPA, so by passing the endpoint in the template they can allow the actual URL for that page to be set in the controller, maintaining cohesiveness. E.g. on the server-side .html.erb they'd have something like ` ... `

Just feels like you're halfway following good JS practices. Ex: using Vue is great, but still rendering templates the "old way" instead of server rendering correctly for the whole app and having components remount. Totally get your point :)

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

#26
post #2

Why is GitLab putting data into their html? "You can pass your endpoints in through the data attributes." Why store endpoints and other js related data on a DOM element. This sounds like a left over paradigm they kept from their jQuery mindset, or am I mistaken?

Hi! I am a Frontend engineer at GitLab.

Our frontend application was originally built with Rails. When we added Vue, we did not refactor our entire code base.

This means that we've kept the existing server rendered pages. Once the page is rendered we build our vue app on top of it.

The reasons why we pass certain data through HTML is: 1 - Avoid duplication. Our endpoints and paths are still built in rails, by passing them through data attributes we keep only one single source of truth 2 - Passing data from the server to the Vue App Some data is not being sent through the API, but we still need to access it. For those cases we also use the data attributes.

We know that this is not ideal but it was a mid term solution that allowed us to quickly add Vue.

You can read more about our architecture with Vue in this blog post: https://about.gitlab.com/2017/06/29/gitlab-at-vue-conf/

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

#27
post #26
post #2

Why is GitLab putting data into their html? "You can pass your endpoints in through the data attributes." Why store endpoints and other js related data on a DOM element. This sounds like a left over paradigm they kept from their jQuery mindset, or am I mistaken?

Hi! I am a Frontend engineer at GitLab. Our frontend application was originally built with Rails. When we added Vue, we did not refactor our entire code base. This means that we've kept the existing server rendered pages. Once the page is rendered we build our vue app on top of it. The reasons why we pass certain data through HTML is: 1 - Avoid duplication. Our endpoints and paths are still built in rails, by passing…

Awesome, makes perfect sense :) I get why you guys have to do this now.

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

#28
post #12

Earlier quoted context omitted.

Funny thing is, Vue wihtout extras is more complex than React without extras.

no, it's actually quite the opposite. vue took all the complexities out of react/redux it's not even funny.

I'm not talking about Redux.

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

#29
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’t say the same about React, even though I’m a big fan of both.

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

#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 beginner in Javascript. With Vue's single file components, he could also hack parallely with us while iterating on html/css.

Standard / Official way of doing things

This again is a personal preference but Vuejs comes with a recommended way to do a majority of things. Vuex(state management) and Vue-Router are provided/maintained by same Vue core team.

React at times can be overwhelming for beginnners, just because of the amount of choice available

Example:

Google Search for 'React CSS style' [https://www.google.co.in/search?q=react+css+style] points to a bunch of links all of which link to valid solutions, but I have to go through a few of them before I get what I am looking for.

Similar search for 'Vue CSS style' [https://www.google.co.in/search?q=vue+css+style] all top links lead to official documenation on vuejs.org.

Excellent documentation

Also, as a team we were primarily writing Angular 1 when we decided to choose a frontend framework for newer projects. I feel this also made our transition to Vue easier vis a vis React

Post reply on HN