Last updated: 25-MAY-2022
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.
If you have already tried or plan to try our new PDF Export API and want to share your feedback, please refer to this discussion page.
This new API also addressed requests to specify custom position for newly added rows in our DataGrid.
You are welcome to follow the discussion on this new API here. We’ll update the thread once this API is publicly available and ready for early testing.
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’ll post an update in this thread once our implementation is ready for review.
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:
We expect to ship the following new DevExtreme Diagram customization features in 2021-2022:
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 is not enough for efficient bundle/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-2022 - 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. Join the discussion on ES6 modules support and share your feedback (we definitely need early testers).
The Google team constantly updates its Material Design Guidelines. We plan to incorporate relevant changes and previously planned Editor Label Animations. If you have any specific requests about Material Theme support in DevExtreme, feel free to let us know via the feedback form below this post.
Your feedback helped us fine-tune our vision. The features we'll introduce in 2021-2022 depend on continued feedback/engagement with all of you – and of course available resources.
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.
If the ”nativeness” related enhancements are important to you and you want to participate in early testing and technical discussions, please let us know via the form below or simply track this GitHub thread.
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 2022.
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. If you want to forward specific issues as they relate to TypeScript, feel free to comment in this thread.
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.