[DevFest Nantes 2019] Building a Complex Application with Web Components and LitElement

[@YinonOved]

Would be nice if this whole talk gets written down to segments on a blog post. Each section of the talk can be described more deeply. Glad I found this talk anyway

[@johnfunk1815]

This is such an amazing talk. I've been looking for something like this for years. The event resolution protocol is such a slick approach. I think I'm going to be unpacking this talk for months. Thank you so much for sharing it!

[@bertolimauro]

great talk from Justin Fagnani, thanks to share it

[@marcocanali7277]

Tanta ... tanta Roba! Of course we need this talk update each year ... ! Hope to see in next SF Web Components MeetUp ...

[@theoligarchist1503]

This video is helping me create my own SPA Framework, its packed with good useful info about Architecture coding. :-)

[@rongsenng]

Classic page.js makes a return in this talk. In early Polymer, we used to use page.js for routing if you Polymer users still remember this.

[@Rtzoor]

fantastic talk! i would love to hear much more about all of this and all the topic you didn't have time to touch on

[@magictom8]

Great talk. If anyone is confused like I was when trying to re-implement `requestInstance` using the latest lit, I found I needed to add `composed: true` as a property in the `CustomEvent` object.

[@punkkabestia]

Amazing .... i miss so much Polymer Summit !!

[@janoschkax]

very elegant! ! lit - killing boilerplate since.. 2019?

[@avi7278]

jeez can you imagine having that last name as a kid.... relentless.

[@denizdavutoglu]

I was really excited when I find out about this talk. But I get frustrated when you start to mix things like typescript, decorators, redux. I try to switch to native web components with plain js to get rid of all this things.

[@YinonOved]

Deniz Davutoglu decorators are brilliantly helpful and are a pending proposal

[@denizdavutoglu]

@@YinonOved why you take just part of my concerns? Decorators are spice not must, but if you are aiming to write Spa with web components state menagement is must. Typescript is path that kills all flexibility of javascript redux is pattern that doesn't fit in js word. Try to see it holistically not from narrow key hole.

[@YinonOved]

@@denizdavutoglu partially agree on typescript, redux is a state management approach which u don't have to follow if u don't see it fit. decorators are helpful in declarative term. not must. you are right on differentiating it but I'm just saying it's really nice. i love the opportunities I get to write decorators when it make sense.

[@denizdavutoglu]

@@YinonOved when I see video about building complex apps with native Web components, I would expect topic to be all about it. I found his approach quite lazy. Redux come to our life just because lack of engineering skills of react team. If you go native you can use simple singleton pattern with custom events. Browser already provides everything we need. React was ommitimg most of browser skills. I try to switch to native components to get rid of all monstrecity caused by react. This is reason of dissapoinment I have about this video.

[@brainoverflow98]

@@denizdavutoglu Hocam merhaba front-end tarafına yeni yeni adım atan birisiyim. Aklımda standart teknolojilery kullanarak mümkün olduğunca native gitmek vardı. Araştırma yaparken Web Components hakkında yazılar buldum. Ama anladığım kadarıyla sağladıkları API'ler DOM updateleri yapmak için değil daha çok UI'i componentlere bölmek üzerine. Performanslı DOM updateleri yapmak için lit-html veya lit-elements gibi kütüphaneler kullanmamız gerekiyor. Bu seçenek bana Angular, React, Vue gibi frameworkleri kullanmaktan daha mantıklı geliyor. Ama bu frameworklerin başka avantajları olduğunu savunanlar var. Böyle bir konuda sizin fikriniz nedir? Front-end'e yeni başlayan biri native'e en yakın nasıl bir yol izleyebilir ?

[@aleksandrmatyka3118]

Can you please tell me how to use the decorator syntax, the property property in conjunction with the redax? I want use @property({type: Array}) stages instead of static get properties() { return { stages: {type: Array} } but this property defined in _stateChanged(state) { this. = state.reducer.stages } so it posible?

[@ashishshubham]

Why do we need Dependency injection via events/context ? Why cant we just `import` the required dependency ? If it is dynamic we could have a singleton which can store the dynamic value and the requestor can then just import the singleton and read the dynamic value from there.

[@Donskelle]

Good point. Handling state in components is pretty nice. Ofc its not fast, if you trying to be super performant(not necessary in most cases).. You can just wrap your customer-view in a customer-data component. Its just more declarative. What happens to singletons when they aren't in use by any component? Do they stay in memory? Guess not, i dont know....

[@nandoflorestan]

I think the answer is, DI is a mechanism to decouple the widget from the application. If you are developing a web component to be reused in many applications, then it certainly cannot just import a singleton, since it must not know anything about the app or the way it manages its data.

[@blahblaahblaaah]

one thing others have not mentioned: testability. with DI you can inject mocks/stubs into your code under test, allowing for better isolation, faster and more reliable tests (e.g. avoid hitting network). and this can be done without complex module based mocking as in jest. it's worth reading up on DI/IoC in general, as these are well documented benefits.

[@davidmaxwaterman]

Annoying when the video doesn't show the slides...

[@davidmaxwaterman]

The number of times I am shouting at the camera man to show me the code! Sheesh.

[@1Joren]

At 20:10 an event listener is added in the constructor of the component. To my knowledge, this does not work, and needs to be added in the connectedCallback instead, right?

[@rongsenng]

I guess that should work since the event listener is only attached to the element itself. This might be a different case if the event listener were to attach on a rendered content after render. Correct me if I'm wrong.

[@1Joren]

@@rongsenng Yes, if you were to attach an event listener to anything other than the host element (so e.g. a button inside the template of the component), you would do it on firstUpdated instead of connectedCallback :).

[@jonas-tm]

Is there somewhere the complete code to download?

[@ArcodeBonte]

Has anybody found the code or comparable code?

[@chandruskc]

Still looking for the code

[@arkanciscan]

ChromeOS is getting a WC powered drawing app? Cool!

[@travistrue2008]

Definitely be careful with mixins. People can get carried away (especially when they're coming from OO-heavy languages like Java or C#, and discover mixins), and they end up inflating the scope of the component itself instead of breaking things up into smaller components with more targeted purposes. The only proper use that I've seen so far is pwa-helpers' connect() function for Redux. I think connect() is a really good example of mixins too because it focuses on treating itself as a pure extension of the variable base class that it's meant to derive off of --it makes not assumption of the underlying base class's implementation. This is key because in violating the pure extension rule (for lack of a better term), you'll end up with a mixin that relies on the base class somehow fully implementing all of the base class dependencies. This gets dangerous when the mixin developer begins to think in terms of getting mixins to work together: implementing a mixing that assumes that the base class also extends another specific mixin at some point. This quickly devolves into a hole, notha, levol, of code spaghetti.

[@wilhelmpaulm]

damn