-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native components for Angular, React, and Vue #16468
Comments
Please don't take away support for KnockoutJS, I know you guys no longer advertise it; but we have built a large scale application on the Knockout framework and DevExtreme. |
First of all, great to read this in your roadmap! 👍🏼 I think examples that show the different limitations / quirks of the current "wrapper" solution would be very helpful and need to be collected, ideally with an example of how a framework-native solution would look like. We as users could add them, and maybe more such examples can be collected from support tickets? And just an idea, if we don't want to pollute this ticket, that collection could happen in separate tickets per target framework. |
@b1tzer0 We use KnockoutJS-based DevExtreme components in our own products, so we don't have immediate plans to abandon it. @sbusch You are right. That's why I decided to create the Google Form referenced in my original message to collect such cases. Everyone is welcome to submit as many forms as you need to share every single use case for your target framework. |
Oh sorry, I jumped directly from your roadmap blog post to the GitHub comment field. Should have read the ticket first :-P Sorry for spamming... |
Angular, React, and Vue already outdated, switch to web components technologies, and it will be as you wrote "fully native internal component architecture". I have already tried running dxDataGrid in the shadow DOM, the component displayed correctly and even functioned, and if you do 2 things:
then the task will be solved. |
@Leon-Alexey Thanks for your feedback.
According to Google Trends, web components are not a mainstream technology so far: We, as developers of a UI component library, don't see much traction for web components among our users either. Anyway, we expect that the way we plan to deliver 'native' components for modern frameworks will allow us to deliver 'pure' Web Components quite easily once we see more demand for them. Regarding the use of DevExtreme components within Shadow DOM - we plan to support it even if we don't ship our suite as a set of true Web Components. |
because we were waiting for support from Microsoft, support has appeared, and by inertia everyone is waiting further, who will be the first. |
@Leon-Alexey Thanks for the clarification. It's nice to hear you find Web Components suitable for your development needs. I'm just wondering if you have any experience with Angular, React, or Vue. The Web Components technology and the mentioned frameworks are not mutually exclusive. The latter are made to make things more declarative - easier to develop and maintain. How do bind your application state to UI (update web component properties, handle events, etc.)? Another interesting aspect is Server-Side Rendering (SSR). Using Angular, React, or Vue it's possible to render the final markup on the server-side out-of-the-box. With Web Components, it might be difficult due to the Shadow DOM concept. |
At the danger of sidetracking this conversation let me add my five cents on the combination of Web Components, Angular and DevExtreme. Overall I ran into two main issues:
Due to the latter issue my Web Components currently do not use shadow dom. This is a real bummer and I would truly appreciate if both issues could be solved with the switch to native components. The first one should be trivial as noted above but I didn’t dig deep enough into your event handling code yet to comment on the complexity of the second issue. |
I'd like some clarification on the plans for the Reactive grid. We recently came across this post where a DE developer seemed to be recommending against the use of the Reactive grids: If the position of DE is that we should not be using Reactive because it will be phased out, I would expect to see this in a blog post of some kind? Our team recently renewed our licenses to DE on the back of our good experience with Reactive. We found it significantly easier to build complex features upon because the compositional nature of react allowed us to fully replace any part of the grid, and the lack opaque API's meant that everything worked the way that a normal react app would work, without any surprises. We also found the performance significantly better than ag-grid, and because the grid is just normal react, we were able to utilize our own optimized state-management solutions pretty transparently. I would hate to see this go, but would really like some clarity if this is no longer the direction DE is going. |
@Leon-Alexey Thanks for the link, we'll monitor how it's going. If it turns out to be a new mainstream – of course, we'll alter our strategy accordingly. @iansudderth I'm happy to hear about your good experience with DevExtreme Reactive. We revealed our plans regarding this suite in our latest Roadmap blog post. Let me quote it here:
Also, I'd like to comment upon your concerns:
That's our goal to deliver the native React advantages you've mentioned within our main DevExtreme product line. The team is working on it right now, but as you understand it's an extremely challenging task to recreate DataGrid/Scheduler almost from scratch and minimize breaking changes for existing users. |
Our application is based on DevExtreme Angular a lot, especially One problem we found is DevExtreme components have some dx-events like Another problem is, as our application is large, we have to create our data grid based on |
The Problem
The JavaScript world evolves rapidly. As such, we must fulfill user demand whenever a popular JS framework appears or an existing framework receives a major update. Our commitment is then to produce quality products and ship them as soon as possible.
A few years ago, we decided to wrap existing JS components for Angular, React, and Vue, so you can leverage our 70+ JavaScript components with your framework of choice immediately. Now, we want to go even further and eliminate the perceived disadvantages of ‘wrappers’. We are still at the research stage and will post updates on this topic once we have something relevant to share.
As it relates to “nativeness”, we have three specific objectives for DevExtreme:
Native API & Lifecycle
Our current API allows you to implement almost any usage scenario, but in some instances, our API may not “feel” native. There are times when API requires direct DOM access or instance method calls instead of declarative bindings. While at other times, you need to use DevExtreme-specific events instead of the target framework’s lifecycle events. We want to address all these scenarios, and deliver native declarative APIs and support native lifecycles.
Native Data Binding
DevExtreme ships with a powerful data layer that encapsulates and simplifies the complexity of client-side data processing and remote HTTP request handling. However, you may need to bind components directly to your local application state. This state can be represented by static arrays, observable arrays, Redux or NgRx store, etc. We are working to improve the developer experience and deliver a straightforward solution to address these usage scenarios.
Native Rendering
Each JS framework comes with its own philosophy and core technical foundation. React and Vue are based on Virtual DOM, Vue and Angular use observables, etc. Multi-thread rendering using Web Workers is on the horizon. All these techniques come with their own benefits - from better performance to server-side rendering support. While DevExtreme wrappers leverage some of these benefits, we can do more. We are looking for ways to deliver all of them through fully native internal component architecture and have produced promising results. We look forward to sharing our solution with you once we complete this task.
The Proposed Solution
Since DevExtreme already has a massive userbase, we tend to think of these architectural/API changes as evolution rather than revolution. As such, we want to rework DevExtreme architecture gradually and release renovated components one by one. Note that to release a native DataGrid, we’ll need to first rework all its dependencies (buttons, editors, dialogs, etc.).
Our strategy in this case:
We expect each DevExtreme component to pass 2 stages:
We Need Your Feedback
Since there are many things to address in terms of ‘nativeness’, we need more specifics in the context of real applications you are working on. We want to know about the issues you find most problematic and critical to you, in which use cases you encounter them, and how you expect us to resolve them. This information will help us prioritize our efforts and deliver better solutions according to your specific needs.
Please share your suggestions and comments using one of the following:
We will regularly ask you to review and test the architectural changes we introduce in your applications. We appreciate your time and ask that you consider participating in our collaborative work as we align internal DevExtreme architecture with your specific needs. Don’t forget to subscribe to this thread for updates.
The text was updated successfully, but these errors were encountered: