What is the motivation behind the widget class api? #8110
Replies: 3 comments
-
Thanks for taking an interest in the widgets effort.
Because these are events that happen inside the Deck instance - "render" refers to when Deck redraws the WebGL context; "click" refers to when an object in a layer is clicked; etc. So yes, these are our own APIs, and they can only be supported if the core is aware of the widgets mechanism.
I have nothing against WebComponents, just not clear how it will benefit us. |
Beta Was this translation helpful? Give feedback.
-
Thank you |
Beta Was this translation helpful? Give feedback.
-
It seems to me that Web Components could perhaps still be an option for how to package up these widgets and make it easy to use them in all web apps. We do want something that is "standard", works with pure javascript and independent of framework (React etc). @chrisgervang FYI. |
Beta Was this translation helpful? Give feedback.
-
Hi guys. Let me start by saying I love this lib so my question comes from a good place :)
What is the motivation behind the widget class api?
This clearly seems to represent some component.
So why not use WebComponents? ( its a standard since 2018 and you don't have to use the ShadowDom)
Why introduce your own api for render, click, drag etc..?
Seems like more code to maintain?
Also, why put the manager in core?
Deck.gl has always been remarkably clean in their separation of concerns!
Sorry to bother you with these questions, but I do not know the place where you are discussing these things.
Thanks for reading!
Beta Was this translation helpful? Give feedback.
All reactions