[zackify]

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?

[filipa]

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/

[zackify]

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

[ftxrcc]

Because it works, it's simple (requires not much overhead), and sometimes it's just the best option.

This "hurr jQuery and everything it brought sucks" mentality is not good.

[zackify]

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.

[dubcanada]

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.

[gravity13]

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

[zackify]

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.

[pythonaut_16]

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

`<div... data-endpoint="@controller.url">...</div>`

[zackify]

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 :)

[pythonaut_16]

I don't disagree but the real power of Vue is that you can immediately start using it in your existing application without having to jump to a full SPA. Vue works just as well when added to a single page or feature in an existing application as it does in a full SPA