Topic

Should we consider a virtual DOM for Dojo 2?

Considerations

There are several considerations that should be made about a virtual DOM for Dojo 2:

• Perceived benefits:
  • Allowing batching/diffing of DOM operations to improve perceived user responsiveness
  • Insertion of a control point between Widgets (and other DOM operators) and the DOM
  • Ability to support serialization of DOM actions which allows for easier isomorphic code
• Perceived disadvantages:
  • Additional overhead on the client
• Should a virtual DOM include the full sub-set of DOM operations, or only those operations we would want people to use in the construct of a Dojo 2 Widget?
• Are there existing libraries that are sufficient to integrate into Dojo 2?

Thinking about how we should format distributions, I was thinking something like this:

dist
└ umd - individual UMD modules with external sourcemaps
└ es - individual ES6+ targeted modules in es6 module format
│      with inline sourcemaps and sources (essentially for
│      rebundling)
└ src - source TypeScript files
└ typings - Any typings for the package, including the packages typings
  index.js - a UMD module that contains all the packages modules in a single bundle
  index.min.js - a UMD module that contains everything minified
  index.js.map - A sourcemap file for index.js
  index.min.js.map - A sourcemap file for index.min.js
  package.json - CommonJS package meta-data
  bower.json - bower package meta-data
  README.md - Package's readme
  LICENSE - Package's license

I think it will be important to consumers to have easy ways to consume the packages in different workflows. I would expect our build pipeline would eventually just grab the /src and keep rolling things up into a final distribution build, but I can see where people will want to grab things like /es and use Babel or something else to do their targeting won't need to have TypeScript installed.

• [x] Review all dojo packages to verify that they state clearly if they are part of Dojo 1.x or 2.0+
• [ ] Update org description to be clear about 2.0+ vs. 1.x
• [x] Update URL in org to dojo.io (verify we're ready for that)
• [ ] Do something about dojo/dojo2 package as that is completely confusing now (would require updates to Intern and perhaps others)

One of the use cases that the Dojo 2 website should support is to allow users to download any tutorial so that they can explore it locally. To support this, a new cli module should be created that exposes commands that allow a user to install a specific demonstration app along with all of its dependencies so that the user can immediately build and run it locally.

Setup workflow to generate API docs for Dojo 2 packages. Things to consider:

• Will we do something similar to Leadfoot and DigDug ( https://github.com/SitePen/jsdoc-catalyst-theme and https://theintern.github.io/leadfoot/ )?
• Will we build API docs per package or one view for all packages?
• Will we set this up to automatically rebuild nightly? Per new tag? Manual only?
• Multiple version support?
• Host on GitHub or Dojo web site?
• Integration with other documentation (e.g. something like a reference guide or tutorials, demos, etc.)?
• Other things to consider?

Story

Dojo 2 needs a set of tooling to make building Dojo 2 applications straight forward, as well as an easy way of managing dependencies of Dojo 2 packages.

Features

The proposal should express the following features:

• Ability to easily include dependent packages
• Ability to build from TypeScript source, including all source packages that are written in TypeScript
• Build time concatenation/layering
• Build time minification
• Generation of typings for a package

Considerations

There are several things that should be considered:

• Minification for TypeScript could benefit from a minifier that is integrated into the language services (see: Microsoft/TypeScript#8)
• Overall dependency management and typings is still up in the air (see: Microsoft/TypeScript#5537 and: typings/typings#3), although we have dts-generator this is likely limiting in the future.
• There seems to be more support for typings than DefinitelyTyped going forward.
• GruntJS is our preferred task runner, but are their other considerations?
• Should we support the RequireJS extensions to AMD for build time plugin resolution? (see: dojo/loader#31)

@rishson commented on Mon Jan 16 2017

We need to consider what layout mechanisms we want to support in Dojo 2. We should consider css-grid support, flexbox support etc. We need to decide if we recommend 3rd party grid solutions, write our own, provide advice only...

@matt-gadd commented on Wed Jan 18 2017

@rishson I think this issue should be moved to dojo/meta.

@bitpshr commented on Fri Jan 20 2017

Thinking out loud, all our widgets are still rendered as DOM. Users can always write their own CSS to lay widgets out however they want. What would Dojo 2 provide as a framework to facilitate this? We should probably avoid anything resembling dojo/layout.

Dojo 1 used less as a pre-processor, but largely the team has felt that wasn't the best decision and subsequent development has focused on Stylus.

SASS is very popular as a CSS pre-processor, but being based on Ruby increases the dependencies on what is largely a design-goal of having JavaScript based tooling for Dojo 2. There would have to be a compelling reason (in my opinion) to adopt SASS.

In addition, with a desire to utilise FlexBox for layout with Dojo 2 widgets, there maybe a need for either using a post-processor or a some sort mixin solution (e.g. nib for Stylus) for the pre-processor to be able to transform the CSS.

We also need how a pre-processor would work along side any sort of CSS modularity solutions (see #28).

One of the challenges with modular code is that it also can be a challenge to manage CSS in a modular way and be able for code to be explicit about what CSS is required. Web Components solves this problem by integrating the logic (JavaScript), structure (HTML) and presentation (CSS) into a single entity which is loaded.

Since the direction of Dojo 2 isn't to solve this encapsulation problem via the Web Components architecture we need another mechanism for managing CSS. The options I can see we might consider:

• Package Level CSS - Each package would have the CSS for all the widgets that it contains and additional themes could/would be loaded on top of the base CSS. A pre-processor can be used for making it easy to maintain. The challenges with this is that it becomes difficult to build time optimise any of the CSS and it becomes an all or nothing proposition.
• Adopt css-modules - A specification of how to modularise CSS and keep it easily tied to the code. This has the advantage of making the CSS dependencies clear. This would require an AMD plugin, one that may even integrate with a pre-processor, and do a build optimization step. Because a definitive dependency graph could be determined at build time, this likely would end up in fairly well optimised built CSS.
• Follow a pattern, like Radium, which favours inline styles which can be expressed in a syntax similar to CSS, but calculate and set the styles at DOM rendering time. This has the advantage of logic being able to manipulate the styling.

There maybe other patterns we could consider, but these are the ones that come to my mind.

Topic

Should we adopt ImmutableJS as a core design pattern for Dojo 2?

Background

ImmutableJS provides a library for dealing with immutable data.

Immutable data cannot be changed once created, leading to much simpler application development, no defensive copying, and enabling advanced memoization and change detection techniques with simple logic. Persistent data presents a mutative API which does not update the data in-place, but instead always yields new updated data.

Immutable provides Persistent Immutable List, Stack, Map, OrderedMap, Set, OrderedSet and Record. They are highly efficient on modern JavaScript VMs by using structural sharing via hash maps tries and vector tries as popularized by Clojure and Scala, minimizing the need to copy or cache data.

Immutable also provides a lazy Seq, allowing efficient chaining of collection methods like map and filter without creating intermediate representations. Create some Seq with Range and Repeat.

Considerations

• How would we integrate ImmutableJS?
• How would it integrate to our build pipeline?
• What APIs should we change or replace or augment to leverage ImmutableJS and how do we expose it to the end developer?

Although Dojo 2.0 not being ready yet, the dojo roadmap looks very promising! Glad to see that our framework of choice a few years ago is still evolving (a year back, we were biting our nails if Dojo 2.0 would ever see the light of day!) and nearing completion.

In order for us to prepare for a possible upgrade to Dojo 2.0, it would be quite handy if there would be an upgrade/migration guide on how to proceed/prepare!

I've found this migration guide, but it looks as if this is very old and doesn't reflect the (massive) changes made to the dojo core in 2.0.

We're on Dojo 1.11.1 now and would like to make an estimate on how much work it would be to upgrade to 2.0. I'm hoping that it's somewhat backwards compatible, but looking at all the new packages i'm guessing that this is not the case. Please correct me if i'm wrong :)

Keep up the good work and thanks in advance!

Wanted to share this FYI out to the Dojo community to let ya’ll know that the OpenJS Foundation has opened its call for speakers for the upcoming virtual OpenJS World event on 9 June 2021. We would love to make sure the project is well represented in the conference content! If anyone is interested and has more questions, wants help writing an abstract, or wants to get involved with the CFP Reviews, email me at jory @ thestoryofjory dot com or ping me in Slack.

We’d also love your help getting the word out about the event - if you’d be up to putting a link or banner on the project website, tweeting from your project account, etc. we would be very grateful!

Hello, I'm following your website (https://dojo.io/tutorials/001_static_content/), and used npm to install @dojo/cli and @dojo/cli-create-app, the execute command like this :

#!/bin/bash
npm install -g @dojo/cli  
npm install -g @dojo/cli-create-app
dojo create app --name first-dojo-app   # right here, the program noticed npm install error, and just exit, the error msg notice because dojo-interface was deprecated, so install is not totally finish, so i use yarn to install
cd first-dojo-app
yarn # instead of not full npm install
dojo build -m dev -w memory -s  
# after execute this command, the dojo print "Invalid response from npm search" info, but i don't know where the invalid response is, and what the invalid content is

This is my system info and npm,node env version: 1, node v8.4.0 2, npm v5.3.0 3, Ubuntu 16.04.2 LTS 4, yarn v1.1.0

Is that system environment not satisfield? Should I need to release version? Or change the npm source url? Or dojo cli tools is not compatible with the Linux system?

I wanna to use dojo, and wanna study by dojo website, but cannot success create app step by step, could you help, Thanks a lot

HI,I am trying to include custom JavaScript files using script tag in index.html.But in browser it shows the error 404 file not found.I have tried all different types of including.some one can tell me how can i include a js files into Dojo 2.

I reported this already under: https://github.com/dojo/interop/issues/36 but this bug tracker seems not to be very active, so I am cross posting it here.

Both, the sample code and the setup from the turorial: https://dojo.io/tutorials/1040_dojo1_dijits/ and the docs: https://dojo.io/docs/index.html#doc--dojo__interop__v2_0_0 give me the error: Module build failed: ReferenceError: define is not defined

for details see the full bug report under: https://github.com/dojo/interop/issues/36

At the moment to import images in Dojo you have to use require.

For example say we want to use an image in a widget, we must do it like so:

const bottomImage = require('./../images/placeholder.png') 

It would be consistent and idomatic to be able to do image imports as we do with modules like this:

import bottomImage from './../images/placeholder.png';