Last updated: 24-February-2021
The information contained within this Roadmap details our current/projected development plans. Please note that this information is being shared for INFORMATIONAL PURPOSES ONLY and does not represent a binding commitment on the part of Developer Express Inc. This roadmap and the features/products listed within it are subject to change. You should not rely or use this information to help make a purchase decision about Developer Express Inc products.
As you may already know, in v20.2 we forked Quill v2.0 to add a highly requested feature - Table Support. Another positive outcome of this fork is IE11 support - something that survey results suggest remains important for a large number of DevExtreme users. Originally, IE11 support was dropped by the Quill team in Quill v2.0.
This year, we will incorporate the following new features into our HTML/Markdown Editor:
Virtual Scrolling was first introduced in v20.2 and was made available in vertically grouped day and week views. Virtual Scrolling improved performance when displaying hundreds or even thousands of events/groups. In v21.1 this enhancement will be extended to timelines and horizontally grouped day and week views.
We continue to address requests regarding recently released components such as Gantt and Diagram. Most requests are related to component customization. In 2021, we’ll add the following customization capabilities to our Gantt component:
Another important and highly requested feature we expect to incorporate is PDF Export. In development
We expect to ship the following new DevExtreme Diagram customization features in 2021:
We will extend the DevExtreme File Manager and make it more customizable with the following new APIs:
A lot of work has been done in the regard to better Tree Shaking, but much work remains to be completed for better Code Splitting. Last year we reworked DevExtreme modular system to deliver ES6 modules in DevExtreme NPM packages. The final “mile” was unexpectedly long – as issues prevented us from shipping ES6 modules inside v20.2.
Note, ES6 modules make it technically possible to efficiently tree shake code. Unfortunately, this not enough for efficient bungle/chunk size optimization. Modules themselves need to be small and independent from one another. Large components should not be monoliths. That’s our goal for 2021 - make existing modules smaller and more independent - and split large monolith components into separate modules. We don't expect to finish everything in this regard this year, but we expect to eliminate the most problematic issues.
The Google team constantly updates its Material Design Guidelines. We plan to incorporate relevant changes and previously planned Editor Label Animations.
As it relates to “nativeness”, we have three specific objectives for DevExtreme:
Our current API allows you to implement almost any usage scenario, but in some instance, our API may not “feel” native. Sometimes the API requires direct DOM access or instance method calls instead of declarative bindings. Sometimes you need to use DevExtreme-specific events instead of the target framework’s lifecycle events. We want to address all these issues and deliver native declarative APIs and support native lifecycles.
DevExtreme ships with a powerful data layer that encapsulates all the complexity of client-side data processing and remote HTTP request handling. This notwithstanding, in some instance, 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 plan to improve the developer experience in this regard and deliver a straightforward solution to address these usage scenarios.
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 via Web Workers is on the horizon. All these techniques offer benefits - from better performance to server-side rendering support. While DevExtreme wrappers leverage some of these benefits, we can do more. We are researching ways to deliver all of them via a fully native internal component architecture. We’ve already got some promising results in this regard, but still have some core issues to address before we can share our solution with you.
Another key area of focus will be TypeScript support. Thanks to your feedback, we know what to do and which use cases to address. First, we want to replace ‘any’ type with specific types wherever possible. Second, we expect to make event arguments strongly typed and extract these types/interfaces so you can use them in your projects.
This year we plan to allocate more resources to documentation. The mix of technologies on our website is confusing, so we plan to have dedicated websites for each JS framework we support. For instance, if you target React, you won’t be distracted with Angular or ASP.NET-related examples or documentation topics. Additional examples and demos for each framework are also on the horizon.