Reference guide: Bridging from Dojo 1.x to Modern Dojo

[vansimke]

Covering use of @dojo/interop. Update & streamline content from

• https://github.com/dojo/interop/blob/master/README.md
• Possibly remove content around Redux integration (as we should be promoting Stores instead)
• Possibly remove a lot of the manual bridging code in favor of automated upgrading commands

[vansimke]

I've been thinking about taking this issue over the past couple of days. The way I see it, there are several paths that one might want to take when they have a DTK (Dojo 1) app and they want to start migrating to Modern Dojo.

Complete rewrite

• With this approach, an entire application would be rewritten in Modern Dojo. This promises to be the most challenging approach but has the greatest potential reward since all the old code can be left behind.
• The primary challenge that I see with this approach is how to map the concepts from DTK into Modern Dojo

Cohabitation

• Both DTK and Modern Dojo exist on the same page at same time
• This approach could be used by a team that wants to build new features using Modern Dojo, but cannot afford the time and/or risk of migrating their existing code
• The challenge that I see with this approach is how to allow the DTK and Modern Dojo apps to communicate with each other safely

Use DTK widgets within a Modern Dojo application

• This would make sense if a company has a lot invested in a custom widget library and they want to continue to leverage that while using Modern Dojo
• Defining a safe way for Modern Dojo, with its FRP-based communication to safely wrap DTK, which uses direct DOM manipulation updates via eventing would be the primary challenge I see here

To address each one of these use cases, I propose building a small DTK application that uses the primary tools that it offers (custom widgets, custom events, stores, grids, ...) as a baseline application. This app could then be upgraded along each of the paths documented above to show strategies that can be used to address the challenges in each scenario. It is possible, of course, that one or more of these strategies is excessively challenging which would be valuable to document as well.

@matt-gadd or @agubler do you have any thoughts on this? Are there other scenarios that you can imagine? Any of these that should immediately be written off as impractical?