VUECONF US 2019 | Phenomenal Design Patterns In Vue with Jacob Schatz

[@kyleagronick9627]

This all came together in the end when he showed how to impement undo. It really was elegant. If I ever need undo I'll definitly be reaching for this.

[@Andrey-il8rh]

This talk is better be called "How to use Vue without using Vue". Command - Observer pattern is a vivid example: don't use Vuex, don't use Vue SFC, don't use simple elegant solutions that already built into Vue, but instead just write your own bicycles, way to go Jacob 👍 (sarcasm)

[@TechWithMikey]

I was thinking the same thing loool, just re-creating the wheel

[@SonnyDarvish]

when old programmers try to pick up new frontend frameworks

[@TheodoreRavindranath]

The undo example would have been more useful if it didn't just update local state. How does the command pattern deal with complex hierarchy of asynchronous tasks?

[@DodaGarcia]

For anyone curious about the magic trick, the secret is that when he quickly points at someone, he then puts his hands back together in a different configuration as before.

[@deadleaves1985]

How about you manage state with vuex and use patterns already well established in component-based libraries? Higher-order components and functions and Vue mixins and plugins instead of monstrous OO patterns. Javascript is think really weird language with lots of gotchas and clunky syntax, but really powerful functional side to it, and lots of these patterns can be replaced with clever use of higher-order functions. There is a reason there isn't Gang of Four book with dozens of patterns for functional languages - you don't need that. And what I like about Vue is that Vue components are just basically javascript objects with sensible defaults and bunch of functions with properly bound "this". IMO it really hit this sweetspot of being simpler than React, AND having all the same right ideas about components, AND cutting lots of boilerplate code and being simple. I like that and I want to keep it this way.

[@hachiphan6523]

missing a lot of instruction for formInput and formButton methods. There are no github to show the code for viewer

[@Andrey-il8rh]

I was always fascinated by people who are obsessed with complex solutions and monstrous code structures. Most of the stuff if not all from this talk is an anti-pattern. And it won't get better if you would call it Phenomenal - it will still suck. Why? Because instead of striving for simplicity those "solutions" will make your code obscure and harder to understand. The more I code the more responsible I am for bringing any kind of additional abstractions to my code. You know what I like about XML? It's descriptive and one of the main advantages of Vue is that it gives us this power of writing self-explanatory descriptive XML. And I would rather build 10 simple pieces of HTML markup that have different goals then combine all of that into 1 god object that knows how to do everything! When Jacob showcase the first example of messy forms - to me it's not a call to make things shorter but a sign of bad consistency and absence of a design system in a project. People should have standards in a project for how to name things and when to extend a certain type of components. If you want to better understand how to refactor project into a good usable code - I would highly recommend a course by Simon Allardice Programming Foundations: Refactoring Code. This guy has tons of experience and really knows what he is talking about. Always strive for simplicity and you will likely build a great product. Cheers!

I agree with you. Today had to refactor an overengineered solution that tried to handle so many cases within the same component that just got impossible to keep working with it. Please, please, please, simplicity is key! Even if your code ends being bigger, that doesn't matter. Use complex solutions to solve complex problems.

[@Andrey-il8rh]

@ I've spent last 2 weeks removing ~5000 lines of code from overengeenered project so I can't agree more

[@kyleagronick9627]

I would rather have one form component that knows how to make any type of form but each input type would be its own component built off a schema and I wouldn't use render functions.

[@Andrey-il8rh]

@@kyleagronick9627 how would you build a component from a schema but without a render function?

[@kyleagronick9627]

@@Andrey-il8rh Using the component "is" property or just a bunch of conditionals going over each component type. Django has a great form system and there is a library to serialize the form attributes for Vue that I use. I just pass it a model and a schema and it takes care of every use case I have. For advanced forms I just wrap the base form component and add the advanced fields like a file picker above or below the base component and it can change the model as its emitted out.

[@LumbreraEnMiCamino]

where can i buy a book of pattern design in vuejs?

[@iNerV]

i dont know, but you can buy book about disign pattern in general refactoring.guru/design-patterns/book

[@valentinkhomutenko6308]

21:00 This context thing actually looks like another pattern - Front Controller (Martin Fowler)

[@TheAxeForgetsTheTreeRemembers]

This sounded like a lot of complication for few benefits ... if any. Most of this is only going to make the code more obscure and frustrating to read. Especially if you forget to "predict" use cases, which will happen. Most software can and should be simple, but thanks to this kind of people, we are all flooded with nonsense libraries and their many bugs.

[@Andrey-il8rh]

I can't agree more and I'm really glad that in Vue ecosystem such people are the minority. If only they were somehow validated before giving live talks on such official meetings, lol

[@arminb3939]

The command pattern is a complete overkill not to mention the bulk load of commands that must be written for a more complex scenario. I think event sourcing with rxjs would give you the same benefits with less code.

[@vaibhavnamburi2756]

Jason's great, I follow him on twitter and shares some good points. To this video though I have to say I personally don't agree with the first half (form) at all - very clustered, unnecessarily complicated - my goal as a senior dev is to make code as literal and simple as possible (which is extremely hard most times). The second bit about decoupling components with an event driven eco-system I think holds merit, the implementation of it definitely needs improvement lol but nonetheless, calling this video a "phenomenal design pattern" video would be a stretch

[@stsbmu7169]

Is it still a thing after Vue3?

[@Andrey-il8rh]

I guess it wasn't "a thing" to begin with. Looked more like his own thought experiments to look smart. If you really want to make your app super complicated and look similar to that dude's experiments you can utilize Composition API and wrap TS over it with multiple level of abstract class inheritance, at least it will look closer to framework philosophy and won't end up as something so ezoteric and weird

[@michakowalski4578]

The url is not working

[@TheodoreRavindranath]

The form builder is like pushing all the logic out of Vue back into old OO JS land... not appealing.

[@TeoZarkopafilis]

I agree. This feels like a talk without much actual value. It's best suited for plain javascript other than vue

[@hdauven8434]

"How to do JavaEE in VueJS"

[@TheodoreRavindranath]

@@hdauven8434 :D

[@deadleaves1985]

It's hard to justify this approach IMO, cause it does not provide any significant gains. Ok, you can describe your form as an object literal with some properties or JSON, buuut, how is it conceptually better vs using vue templates? Templates are way more expressive, have better IDE support, and you don't have to drop to low level API's

[@MrChickenpoulet]

Oh at first I thought that was a nice solution to not have a lot of .vue files. What would be prefered instead ?

[@danielcastillo7133]

da faq..

[@s4ndeep1203]

nah

[@charleswoodruff9013]

Jacob Schatz should NEVER EVER do a talk...EVER. Tons of irrelevant info and unnecessary tangents that have absolutely nothing to do with the topic...just for a laugh.

[@Andrey-il8rh]

Yeah, the guy really tries to be "funny" but he is just off rhytm