Convert webcomponents to Vue components

[sukima]

After a discussion from the town hall it was recommended that the current webcomponents be converted to Vue.js for better maintainability and readability.

[bsutt123]

Ahoy!

[danbernier]

It'd be nice to write down specifically our reasoning for this, in light of the features we want, and the reasons that we picked Vue instead of other options. Mainly to help future nhvio folk understand this choice in a couple years, when tech, and maybe requirements, and maybe even the nhvio folk, have changed. It doesn't need to be elaborate, just a bit that lays out the reasoning. (Sorry for the ask; I'd do it myself, but I'm unfamiliar with the reasoning.)

~ This message was made with 100% thumbs.

On Thu, Apr 26, 2018, 07:08 bsutt123 notifications@github.com wrote:

Ahoy!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/newhavenio/newhavenio.github.io/issues/64#issuecomment-384601043, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAzFQYmJgx1BEclfsWvdPXYJtfc1eLLks5tsaqTgaJpZM4TkZiu .

[bsutt123]

So the logic is (essentially) this...

We will have to have some way to create dynamic changes to the Dom. This is annoying to do with vanilla html and javascript because updating and creating the dom to reflect dynamic data (like all the meetups from the meetup api) is annoying.

Currently, this is accomplished with webcomponents, which lets you make a little web component that you create a template and some javascript to dynamically change that html.

Vue is just a more expressive library thats built around using a template and javascript to render the dom. You can use it with a single script, and it gives you access to a lot of really neat things that are more intense to implement in web components (like lifecycle events, computed properties, methods attached to the vue instance, etc...).

Does that jive with your and everyones understanding?

[jnimety]

@bsutt123 what do we have planned that requires dynamic changes to the dom?

[sukima]

The current components encapsulate some small JS/HTML:

• Slack button
• Meetup Events
• Meetup Developers

There has been some confusion about web components in general in past mainly because their use is not as universal among the JS community. Yes they are a web standard but typically their use is as part of a library instead of directly. They are also more bare-bones-metal then most other solutions.

The original intent was to fill the gap that jQuery plugins used to fill but with just web standards. Unfortunately to accomplish that in current browsers it needs the Polymer JS library. The discussion last night was about the benefits of using a popular library that fills the same needs but is more approachable to the general JS community. Moving to Vue.js is a one to one conversion (Vue replaces Polymer, web components are converted to Vue components).

The anticipated end result is that it will produce easier to read and maintain code where the current web component solution has not met the easy to read nor the easy to maintain goals.

[jnimety]

:+1: thank you!

[bsutt123]

thanks @sukima. I have never really used web components so I am not terribly familiar with polymer, its nice to see someone with a bit more experience notice the differences.

[bsutt123]

Hey @sukima I know that you had some interest in Vue, and I spent this morning modifying out build process with webpack so that it could handle Vue Single File Templates (which means that all of our assets run through webpack, which is I think what we wanted to move towards anyways).

I was going to work on replacing this whole section and then making a PR, but do you think its worth it to make a PR that just modifys the build tools and includes a new README section on how to make and use Vue Single File Templates?

I am happy to take a detour to add capabilities to the site so that others can contribute and learn rather than just doing it all myself.

We should still merge #50 first if we can because having a more succinct webpack build and deploy process is probably wise, and this one depends on webpack as well.

[sukima]

I'm not sure. The most I know of Vue is what they show on their homepage. You know a lot more about it and if I'm honest I think it would help to see how you (someone who knows more about Vue then I) approaches the problem. I think I would learn a lot by reading your PRs. Especially to see the side-by-side change from a web-component to a Vue-component.

However, if that isn't easy because the web-compoent stuff is too whack-a-do let me know. maybe we can hook up a pairing session or something.

[bsutt123]

Pairing is almost certainly going to be the most effective way to do it, because I can't read the web components code very succinctly, so it would probably be good for both of us to pair if possible.

Either way, if we use Vue to do stuff I want to make a guide of how to do it within the confines of the our site because I think it will encourage people to contribute if they feel like they can understand how to contribute.

Also as a side note, their documentation is fantastic, especially if you have someone to get you started and then you can just read for all the more advanced stuff.

[jnimety]

@bsutt123 @sukima thanks for working on this.

[bsutt123]

So a clone of Web Components to Vue for the Meetup events is all done. Devin and I are going to pair later to check it out and then once #69 is resolved we can look at getting this added as well, as it is probably best to use webpack to build assets and control dependencies if possible.

I'll starting working on a README for the Vue aspect, of our project and how to do stuff specific to how we are rendering things. I think that Vue has some pretty great documentation so it would be a shame to repeat most of it, though I'll probably highlight the most important parts.