Native components for Angular, React, and Vue

[dxbykov]

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 strive for maximum backward compatibility with a minimum number of breaking changes in the context of wrappers and pure JS components.
• When it comes to “native components”, causing breaking changes may be needed in order to eliminate core architectural issues.
• It will likely take several release cycles to complete the whole set of the “nativeness”-related enhancements (if we include the ‘Native Rendering’ item).
• There will undoubtedly be several new major features/controls that will be sacrificed for these architectural enhancements and the above-mentioned outcomes for developers and end-users.

We expect each DevExtreme component to pass 2 stages:

• The refactoring of the DevExtreme core (extract separate reusable components and migrate to declarative UI rendering).
• Introduction and release of the native counterpart to React, Angular, and Vue.

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:

• Leave a comment below
• Create a ticket in our Support Center (start the subject with ‘DevExtreme Renovation: ...’)
• Submit this form with your feedback.

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.

[b1tzer0]

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.

[sbusch]

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.

[dxbykov]

@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.

[sbusch]

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...

[Leon-Alexey]

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:

1. bind to the shadowRoot node instead of the document
2. provide visibility in the shadow DOM

then the task will be solved.

[dxbykov]

@Leon-Alexey Thanks for your feedback.

Angular, React, and Vue already outdated

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.

[Leon-Alexey]

@dxbykov

because we were waiting for support from Microsoft, support has appeared, and by inertia everyone is waiting further, who will be the first.
we have already tested our sites on web components, and we were impressed with this technology.
you can make block parts of the application, and build applications in the likeness of Lego, the program code becomes much easier.
significantly increases the performance and initial loading of the site.

[dxbykov]

@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.

[MichaelSchreier]

At the danger of sidetracking this conversation let me add my five cents on the combination of Web Components, Angular and DevExtreme.
I’m currently using this exact combination and for the most part it works. We’ll, it can be made to work.
There are quite a few rough edges that one has to smooth over on both the Angular and DevExtreme side but unfortunately there is one big issue with DevExtreme which makes it not play nicely with shadow dom.

Overall I ran into two main issues:

• Many modals (e.g. datagrid’s header filter) are created as children of the page’s body tag and there is no decent supported way to change that.
  There is the trick using the dx-viewport class to define a container for all modals, however, as far as I can tell its location is determined when DevExtreme’s code is loaded initially, i.e. on startup, rather than when a component is being initialized (and it’s one dx-viewport per application, rather than one per component anyway).
  The workaround is to identify those sections in DevExtreme’s codebase where such modals are being initialized and write a custom patch so that they are created either as children of the datagrid for instance or the shadow dom.
  This isn’t terribly hard to do but not particularly convenient.
• The one issue I couldn’t solve yet is DevExtreme’s event handling. As described in a support ticket (not mine) there is a workaround for click events but unfortunately mousewheel scrolling refuses to work inside shadow dom.

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.

[Leon-Alexey]

@dxbykov see link lit 2.0
The future has come.

[iansudderth]

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:

https://supportcenter.devexpress.com/ticket/details/t1010044/reactive-grid-how-to-open-a-context-menu-on-right-click-of-a-cell

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.

[dxbykov]

@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:

If you are not familiar with this product, DevExtreme Reactive is a separate set of components built from the ground up for React. It currently includes native React Grid, Scheduler and Chart components. In the context of what we said above regarding “nativeness”, the future of this product line will be shaped by successes in mentioned in the section above. If we prove the viability of our "nativeness” concept, we’ll be able to substitute DevExtreme Reactive components with more powerful native components for React - a package that will include more than 70 UI controls. Of course, if we go the “nativeness” route, we’ll do our best to make the migration process as smooth as possible for those of you who already committed to DevExtreme Reactive. We expect to support our Reactive components and to introduce minor enhancements in 2021. We don’t plan on any major updates to this product line in 2021.

Also, I'd like to comment upon your concerns:

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.

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.

[devbean]

Our application is based on DevExtreme Angular a lot, especially DxDataGrid, form controls and some charts.

One problem we found is DevExtreme components have some dx-events like onValueChanged as well as some ng-events like valueChange. These two events are different in some components like DxSelectBoxComponent. So I hope these could be fixed in future native versions. If the components could support Angular forms framework it could be better.

Another problem is, as our application is large, we have to create our data grid based on DxDataGrid. But properties like dxi-column cannot be password from our wrapper components to inner DxDataGrid. I hope these dxi-* tags could be some placeholder tags, just for collecting some data, then converts these tags into some array to use inside dx components. In such way, many dxi-* could be given by some wrapper. For clarifying, we want to create some common data grid but some columns are fixed while some are dynamic by each page. For example every data grid in our application has a index column. Nowadays we have to create a service, wrap DxDataGridComponent then subscribe to its onContentReady event, unshift a column into its columns array. It would be better that one day our could add such columns in HTML template easily.