dojo/framework

Dojo Framework. A Progressive Framework for Modern Web Apps

@dojo/framework

Dojo is a progressive framework for modern web applications built with TypeScript.

Visit us at dojo.io for documentation, tutorials, cookbooks, and other materials. This repository contains detailed information on the structure of Dojo, while dojo.io is focused on getting started with and learning Dojo.

Sub-packages within @dojo/framework

There are seven sub-packages that form the framework for building a Dojo application:

• dojo/core - The foundational code of the Dojo framework
• dojo/has - A feature detection library
• dojo/i18n - A set of internationalization tooling
• dojo/routing - A routing service to build web applications with
• dojo/shim - Modules that provide fills of ES6+ functionality
• dojo/stores - A lightweight state container
• dojo/testing - A set of modules to help with testing Dojo

External packages

We have additional packages within the Dojo ecosystem to aid in quickly and easily creating Dojo apps:

• dojo/interop - Interoperability with other frameworks (currently Dojo 1 Dijits and Redux)
• dojo/loader - A TypeScript based AMD loader
• dojo/themes - Collection of Dojo themes.
• dojo/widgets - A set of rich UI elements

Dojo CLI

• dojo/cli - Command Line Tooling for Dojo Applications
• dojo/cli-build-app - A CLI command for building Dojo applications
• dojo/cli-build-widget - A CLI command for building widgets
• dojo/cli-create-app - Command for creating application boilerplates
• dojo/cli-create-theme - Command for scaffolding a widget theme
• dojo/cli-create-widget - Command for creating a widget template and all associated boilerplate
• dojo/cli-test-intern - Command for testing projects with Intern

Support Packages

There are several packages which are designed to support the Dojo platform. Generally these packages are not directly used by end developers:

• dojo/scripts - A package of scripts to aid with Dojo package development.
• dojo/webpack-contrib - Specialized webpack loaders and plugins used by the Dojo toolchain.

Migrating Versions

Version 2.x to 3.x Migration Guide

See the v3 migration guide for details on upgrading from version 2.x to version 3.x.

Version 3.x to 4.x Migration Guide

See the v4 migration guide for details on upgrading from version 3.x to version 4.x.

Version 4.x to 5.x Migration Guide

See the v5 migration guide for details on upgrading from version 4.x to version 5.x.

Version 5.x to 6.x Migration Guide

See the v6 migration guide for details on upgrading from version 5.x to version 6.x.

Version 6.x to 7.x Migration Guide

See the v7 migration guide for details on upgrading from version 6.x to version 7.x.

Examples

We have added a repository of examples which have been built on Dojo. Those examples are available in the dojo/examples repository and are live at dojo.github.io/examples.

Guidelines and Style Guide

There are several documents that are relevant for contributing to Dojo.

• Contributing Guidelines - Guidelines for contributing code (or documentation) to Dojo
• Code Of Conduct - Guidelines for participation in all Dojo OSS communities.
• Style Guide - The style guide for Dojo for packages that do not use prettier
• tslint.json - The configuration file tslint that is used to validate Dojo code against

Dependent Technologies

While Dojo tries to provide a holistic set of tools to build web applications, there are several key technologies where we feel that Dojo would be better integrating and building upon versus building from the ground up.

In order to ensure that Dojo is a solid set of JavaScript tools and libraries, Dojo is built on TypeScript. This provides us with structural design time typing as well as an effective way to communicate the intent of the Dojo APIs. It also provides us the ability to adopt ES6+ syntax features but make distributables that will be backwards compatible to the target browsers for Dojo.

TypeScript and Dojo Compatibility Matrix

TypeScript and Dojo both iterate rapidly. In general Dojo strives for maximum compatibility, with a plan to periodically increase the minimum TypeScript version so we can begin relying on newer TypeScript features. Please review this list when using Dojo:

Dojo version	TypeScript version (minimum)	TypeScript version (maximum)
3.0	2.6.x	2.6.x
4.0	2.6.x	3.1.x
5.0	2.6.x	3.2.x
6.0	3.4.5	3.4.5
7.0	3.4.5	3.8.x
8.0	3.4.5	4.1.x

Licensing information

© 2020 OpenJS Foundation & contributors. New BSD license.

framework's Issues

Update External Projects to @dojo/framework

Update external projects to use @dojo/framework in preparation of a version 3 release

• Dependent projects
  • dojo/widgets#564 (PR)
  • dojo/webpack-contrib#54 (PR)
  • dojo/interop#37 (PR)
  • dojo/streams
• CLI
  • dojo/grunt-dojo2#195 (PR)
  • dojo/cli#244 (PR)
  • dojo/cli-create-app#148 (PR)
  • dojo/cli-create-widget#21 (PR)
  • dojo/cli-build-app#109 (PR)
  • dojo/cli-build-widget#31 (PR)
  • dojo/cli-test-intern#109 (PR)
  • dojo/cli-create-theme#36 (PR)
• Dojo examples
• Code Sandbox
  • compuives/codesandbox-client#988
• dojo/meta

Migrating from Dojo2 to Dojo3

Hi,

We are migrating code from dojo2 to dojo3 and it's working fine in local, but when we are trying to do dockerization we are not able to. Can you please help anyone where I am doing mistake. Below is the docker file commands.

FROM node:8
WORKDIR /src
ADD . /src
RUN npm install
RUN npm install -g @dojo/cli
EXPOSE 80
CMD ["dojo", "build", "--mode", "dev", "--serve", "--port", "80"] 

Proxy adapter instead of having to manually create operations

@matt-gadd commented on Tue Jun 26 2018

Enhancement
If we leverage Proxies, I think we can just about track the appropriate paths and changes to allow the user to simply do object and array accessing and setting rather than having to use the get helper and returning the associated operations.

The following would go from:

function calculateCountsCommand({ get, path }: CommandRequest) {
	const todos = get(path('todos'));
	const completedTodos = todos.filter((todo: any) => todo.completed);
	const operations = [
		replace(path('activeCount'), todos.length - completedTodos.length),
		replace(path('completedCount'), completedTodos.length)
	];
	return operations;
}

to:

function calculateCountsCommand(state) {
	const completedTodos = state.todos.filter((todo: any) => todo.completed);
	state.activeCount = state.todos.length - completedTodos.length;
	state.completedCount = completedTodos.length;
}

This would work via the state object being passed in being Proxy wrapped and everything off it. Every time a set is called we'd create the appropriate operation.

A few caveats:

• Won't work in IE11 (so we need to support the existing way)
• The functions no longer take an input and return an output (would have to think about the testing implications)
• Performance?

Add Travis support

• enable the travis build
• add a .travis.yml

Migrate github issues

Merge, close, or move any open PRs to @dojo/framework. If they're external PRs we should reach out to authors.

Move all issues to dojo/framework.

Support typed children in TSX

@matt-gadd commented on Wed Sep 13 2017

Enhancement

TypeScript now supports typed children in TSX, we need to update our JSX namespace to leverage it by adding the ElementChildrenAttribute.

---

@matt-gadd commented on Tue Jun 05 2018

Okay this doesn't currently work due to ElementChildrenAttribute looking on the ElementAttributesProperty, which in our case is properties. See microsoft/TypeScript#18357

Support default properties

@agubler commented on Wed Jul 26 2017

Enhancement

It could be useful for a widget author to be able to specify default properties that the consumer properties are mixed over ensuring that the this.properties type guard reflects the defaulted properties so that they are not assumed to be possibly undefined.

---

@pottedmeat commented on Thu Aug 17 2017

This could be helpful for the dgrid editing functionality where there is a set of properties that should be used across all instances - things like length, style, etc. - but each row has its own value.

---

@agubler commented on Fri Aug 18 2017

@pottedmeat unfortunately it's very difficult to provide the mechanism and support all the typings effectively at the moment.

---

@pottedmeat commented on Fri Aug 18 2017

That's fine, I was just outlining a use case.

---

@agubler commented on Fri Aug 18 2017

Of course, I think there are multiple use cases for default properties one of which is dgrid. Just wanted to let you know where I had got with trying to implement the feature... it led me down a rabbit hole of typings that I couldn't get quite right unfortunately.

---

@kitsonk commented on Tue Aug 29 2017

This seems to be related: microsoft/TypeScript#16173

There appears to still be some challenges, though it seems like the problem space is better understood. We should think about it and try to make sure we have sufficient issues on TypeScript to help solve the problem (or support already existing ones).

[Projector#merge] Existing CSS classes are not preserved when topmost render toggles rendering

@jcfranco commented on Mon May 07 2018

Bug

When using Projector#merge, if the topmost render toggles rendering (returns valid VDOM or undefined between renders), existing CSS classes are not preserved on subsequent renders:

Package Version: 2.0.0

Code

<!DOCTYPE html>
<html lang="en">
<head>
	<title>Preserve CSS classes when merging</title>
</head>
<body>
	<div id="target" class="preserve-me" />
</body>
</html>

import { ProjectorMixin } from '@dojo/widget-core/mixins/Projector';
import App from './widgets/App';

let visible = true;
const Projector = ProjectorMixin(App);
const projector = new Projector();
projector.setProperties({ visible });
projector.merge(document.getElementById('target')!);

setInterval(() => {
	visible = !visible;
	projector.setProperties({ visible });
}, 1000);

export default class App extends WidgetBase<AppProperties> {
	protected render() {
		const { visible } = this.properties;

		return visible ?
				v('div', { classes: css.app }, [
					v('div', [
						'hello'
					])
				]) :
				null;
	}
}

Demo

Expected behavior:

preserve-me class is preserved whenever the app is rendered.

Actual behavior:

preserve-me class is dropped when the app is re-rendered (1st render is 👌).

Move JSX types to local namespace

@jcfranco commented on Wed Apr 18 2018

Enhancement

It'd be nice to move the global JSX typings to a local namespace since TypeScript 2.8 now resolves JSX via the factory function. This is also recommended in their release notes:

Going forward, we recommend that new JSX-oriented libraries avoid placing JSX in the global scope, and instead export it from the same location as the respective factory function.

---

@matt-gadd commented on Mon Jun 11 2018

We plan to update this when we move to TypeScript 2.9

Add committer checks

• Make sure committers have signed an OSS license
• Make sure code coverage is OK
• Make sure CI runs

Improve middleware for processes to allow universal functionality before executing commands

Enhancement

It would be good to have somewhere to define functionality like handling expired sessions before running processes. Consider an application that hits the server in multiple processes. You need to be logged in to access API endpoints within the processes but your session could have expired. As it stands you need to handle this by running a shared command in every process that will do the session checking. Having a universal way of handling this scenario via middleware would be slicker so that we can execute functionality before running the commands in a process.

Package Version: 3.0.1

Add Slack Notifications

Add support for notifying Slack of builds

Sync new git commits

Sync any new git commits with dojo/framework so we don't lose history

`es6-string-raw` is always false

Bug

shim/string isn't using the native functions like startsWith since the has test es6-string-raw is always false. Tested in Chrome, Edge, Firefox, and Safari where es6-string was true.

This seems like a sniff bug, but if not, then shim/string should be updated to not require es6-string and es6-string-raw to both be true before using the available native ES6 functions at:
https://github.com/dojo/framework/blob/master/src/shim/string.ts#L144

Package Version

3.0.1

Code

Console code using Dojo 1 AMD loader after loading shim/string:

require("@dojo/framework/has/has").default("es6-string-raw")

Expected behavior:

outputs true

Actual behavior:

outputs false

Create a Migration tool

As imports change to @dojo/framework for version 3+ we should create a migration tool to help automatically update import statements for apps to easily upgrade.

Multiple select does not allow selection of multiple options on creation

Bug

Creating a native multi-select in vdom does not allow the initial selection of multiple options. This is a minimal recreation: https://codesandbox.io/s/z39779jv7p

It looks like this might be caused by multiple selected option nodes being added to the DOM before the parent select has had multiple: true applied. This would result in the browser interpreting the selected attribute as if it were applied to multiple options in a single-select.

ActiveLink Component

Enhancement

An ActiveLink component that applies one of more classes when the target outlet is matched in the current route.

render() {
    return v('div', [
        w(ActiveLink, { 
            to: 'foo', 
            activeClasses: [ 'fooActive' ] 
        }, [ 'Label' ]), // applies class when `foo` outlet is matched
        w(ActiveLink, { 
            to: 'bar', 
            activeClasses: [ 'barActive' ] 
        }, [ 'Label' ])  // applies class when `bar` outlet is matched
    ]);
}

Add top-level documentation

• Add a README.md to the root of the framework
• Add .github folder w/ CONTRIBUTING.md and other templates
• Make sure the README has a link to our gitter
• Make sure the README's badges are updated to point to dojo/framework

`createProcessFactoryWith` doesn't allow for inferring state and payload types

Bug

createProcessFactoryWith is used to create a factory that has pre-applied middleware, but the result process creator doesn't correctly infer types from the commands it's passed.

Package Version: latest

Code

import {
	createCallbackDecorator,
	createCommandFactory,
	createProcessFactoryWith
} from "@dojo/framework/stores/process";

interface State {
	foo: string;
	bar: number;
}

const createCommand = createCommandFactory<State>();

const middleware = (): void => {
    console.log("test");
};

interface Payload {
	qux: string;
}

const command = createCommand<Payload>(() => {
    return [];
});

const middlewareProcess = createProcessFactoryWith([createCallbackDecorator(middleware)]);

const myProcess = middlewareProcess('process', [command]);

Expected behavior:

No errors!

Actual behavior:

Typing error using command with middlewareProcess

Argument of type 'Command<State, Payload>[]' is not assignable to parameter of type '(Command<any, DefaultPayload> | Command<any, DefaultPayload>[])[]'.
  Type 'Command<State, Payload>' is not assignable to type 'Command<any, DefaultPayload> | Command<any, DefaultPayload>[]'.
    Type 'Command<State, Payload>' is not assignable to type 'Command<any, DefaultPayload>'.
      Type 'DefaultPayload' is not assignable to type 'Payload'.
        Property 'qux' is missing in type 'DefaultPayload'.

doc for has are misleading

on https://dojo.io/docs/index.html#doc--dojo__framework__v3_0_0__src__has__README_md it states that

has() essentially manages feature flags, returning either a truthy value if the feature is present or a falsey value if the feature isn't present.

but if the feature is not set either via the cli-build-app -f flag or via the the .dojorc you get the error of Attempt to detect unregistered has feature "${feature}.

from the way the docs ready I would expect has to return false when the feature isn't set all at.

Deprecate Dojo 2 framework packages

We need to add a deprecation message to the README.md for

• core
• has
• i18n
• routing
• shim
• stores
• widget-core
• test-extras

We should say that the package is deprecated; functionality has been moved to @dojo/framework; there is a migration tool (and link it: see #13); and the package will still receive bug fixes at least until .

An example of a previously deprecated package is https://github.com/dojo/compose

Warn on not having a theme injected

@kitsonk commented on Fri Aug 25 2017

Enhancement

When using a themed widget, it is a common developer issue to forget to use the @theme decorator to inject a themed CSS structure into the widget. When this is detected a run-time, the widget-core should issue a warning to the developer.

References #584

Improve error information on a test operation

@kitsonk commented on Fri Dec 29 2017

Enhancement

In Stores, when attempting to apply an undo operation that is failing for some reason because the test operation does not pass, currently all you get is:

Error: Test operation failure. Unable to apply any operations.

An error message the provides more context would be more useful, like:

Error: Test operation failed.
    Expected "somevalue" for at path "/foo/bar/baz" but got "othervalue"

Potentially looking AssertionError and potentially moving that to core. The other advantage is it will utilise V8's diffing functionality when thrown, improving the information available in Chrome and Node.

Update docs to support dojo.io

dojo.io pulls a live copy of documentation to display it on the dojo.io site. We need to update the hidden table of contents and update the dojo.io document reader if necessary to support dojo/framework.

Consolidate framework/core modules

Enhancement

There are a lot of historical and outdated modules provided within core that aren't required when working with dojo framework. These modules were originally created based on previous dojo toolkit utils and have mostly become redundant and barely maintained.

There are a couple of exceptions including request and task that could potentially be pulled into dedicated projects with champions to manage bugs and enhancements ensuring that they offer benefit over existing native implementations (such as fetch for request).

However, these modules are not used by dojo framework and shouldn't be needed by consumers. Instead using alternatives such as a fetch polyfill for consumers that need to support IE11.

has, exists & dojorc

Enhancement

has and exists seem to not be consistent in usage. has looks for features set either in dojorc or from the cli-build-app -f flag. where exists only pays attention to features set by add

right now there doesn't seem to be a way to check if a feature was set via dojorc or -f. has throws an error if not set and exists always returns false.

Package Version: 3.0.0

Expected behavior:

i would expect exists to see features set by any method - add, dojorc, or -f

Add git hooks

Restore the pre-commit git-hook that runs prettier

JSDoc suggests param can be an integer, but type is string only

framework/src/has/has.ts

Lines 218 to 220 in aad7e6f

	* @param feature The name (if a string) or identifier (if an integer) of the feature to test.
	*/
	export default function has(feature: string): FeatureTestResult {

Add code coverage

• after CI builds using Intern it should report code coverage
• upload code coverage to codecov.io

className is readonly for svg DOM Elements

Bug

When applying classes to DOM nodes vdom attempts to simply set className on a DOM element if it isn't merging and there were no classes applied on the previous render. However className is read only for svg elements and throws an error like:

Cannot assign to read only property 'className' of object '#<SVGSVGElement>'

Update contributor guidelines

With the move to a monorepo, the contributor guidelines copy will need to be updated as well to reflect that move.

Local storage middleware for stores

Enhancement

A middleware for stores that can be used to persist sections of state to LocalStorage and provides a mechanism to load from LocalStorage.

// usage in a process

import { collector } from '@dojo/framework/stores/middleware/localStorage';

const localStorageCollector = collector<State>(
    'local-storage-key',
    (paths) => {
        return [
            path('my', 'state', 'path'),
            path('my', 'other', 'state', 'path')
        ];
    }
);

const process = createProcess('example', [ command ], localStorageCollector);

// usage to load local storage state

import { load } from '@dojo/framework/stores/middleware/localStorage';

load('local-storage-key', store);

Fix core readme after consolidation of modules

Bug

Update core readme, perhaps not worth publishing on dojo.io either now.

Incorrect access modifier for SymbolConstructor.observable

@jason0x43 commented on Fri Jun 29 2018

Bug

SymbolConstrutor.observable has the default access modifier in @dojo/shim, but should be readonly. Currently it conflicts with recent node typings, which specifically flag observable as readonly.

Previous versions of the Node typings (< 10, 10.x before May) didn't include the observable property on SymbolConstructor, so fixing this shouldn't cause issues with code using older Node typings.

See also: theintern/intern#932

Package Version:

2.0.0

Code

Create a project that includes @dojo/[email protected] and @types/[email protected] and try to build it.

Expected behavior:

It compiles.

Actual behavior:

node_modules/@theintern/leadfoot/node_modules/@dojo/shim/Symbol.d.ts:3:9 - error TS2687: All declarations of 'observable' must have identical modifiers.

3         observable: symbol;
          ~~~~~~~~~~


node_modules/@types/node/index.d.ts:169:14 - error TS2687: All declarations of 'observable' must have identical modifiers.

169     readonly observable: symbol;
                 ~~~~~~~~~~

In my widget, Vnode meta node information cannot be fetched when Vnode is child to a widget

Hi All,

In my widget, Vnode meta node information cannot be fetched when Vnode is child to a widget.
Does it bug, or have other solution?
Sample:

https://codesandbox.io/s/4lqo0w4nzx

description:

if drag "drag me", "Delta" can not show any position. you can debug it. this.meta(Drag).get(key) is return null.

Order independent routing configuration

Enhancement

The order that routes are defined in the routing configuration currently affects which route will be matched when a path can match against multiple outlets, for example:

const config = [
    {
        path: '{param}',
        outlet: 'param'
    },
    {
        path: 'foo',
        outlet: 'foo'
    }
];

When the outlet params is defined first it will considered matched against the path /foo even though the foo outlet is a "more specific match".

The router should be able to determine which is the most specific outlet match, regardless of the configuration order.

TypeScript 3.0.0 Upgrade

Enhancement

Upgrade typescript version to 3.0.0

Prompt widget for routing that renders a prompt before a route has transitioned

Enhancement

Add a new widget that can be used to render a view before a route transition has been completed based on a predicate. The render function would receive two functions that can be used to abort or continue the route transition.

For window reload/refresh, will need to use onbeforeunload and this only support the native browser confirm dialog.

StoreProvider widget that can inject the store into the vdom tree

Enhancement

Add a new module StoreProvider that can be used like any widget within the widget tree, and will inject a store into a renderer function so that state and processes can be passed as properties.

interface State {
	foo: string;
	bar: {
		baz: string;
	}
}

class MyApp extends WidgetBase {
	protected render() {
		return w(StoreProvider, { stateKey: 'state', (store: Store<State>) => {
			return v('div', [ store.get(store.path('foo')) ]);
		}})
	}
}

This will replace the existing StoreContainer in a major release after 4.0.0 and the migration guide and upgrade tool warn that usages of StoreContainer should be converted to use StoreProvider.

Render `key` as dom property in `debug` mode

@tomdye commented on Mon Jun 11 2018

Enhancement

It would be advantageous to render a widget / DNode key onto the corresponding dom node when building for debug. This would be especially helpful when writing integration / BDD tests as the selectors can then target the key as we do in our unit tests.

Pragma to merge properties and replace children on WNodes and VNodes

Enhancement

Currently is it cumbersome to decorate properties and children to an existing WNode or VNode. It would be useful if v() and w() accepted an existing node to merge properties and replace children.

Note: For VNodes, special properties classes and styles need to deep merged.

ActiveLink does not check route parameters

Bug

If you have two links that are identical except for the parameters, ActiveLink will mark them both as active.

Route Config:

{
    path: 'my-route',
    outlet: 'my-route',
    children: [
        {
            path: '{suffix}',
            outlet: 'my-suffix'
        }
    ]
}

The links (using tsx),

<ActiveLink to="my-route" params={ {"suffix": "test1"} } />
<ActiveLink to="my-route" params={ {"suffix": "test2"} } />

Both links will be marked as active when my-route is active.

Package Version: 3.0.0

Expected behavior:

The current params would be checked and only one link would be active.

Actual behavior:

All links to the outlet are active regardless of parameters.

Move @dojo/core breaking PR to @dojo/framework

From the original (dojo/core#405):

Type: feature

The following has been addressed in the PR:

• There is a related issue
• All code has been formatted with prettier as per the readme code style guidelines
• Unit or Functional tests are included in the PR

Description:

When specifically using the xhr provider, the upload events allow access to data available from the native xhr progress event:

const xhr = xhr.post('http://www.example.com/', {
	body: someLargeString
});

xhr.upload.subscribe(uploadData => {
  const { loaded, total, lengthComputable } = uploadData;
	if (lengthComputable) {
		const percentComplete = loaded / total * 100;
	}
});

The node provider has also been updated for consistency:

const req = request.post('http://www.example.com/', {
	body: someLargeString
});

req.upload.subscribe(uploadData => {
	const { loaded } = uploadData;
	// do something with uploaded bytes
})

Support a function that returns a lazily imported widget when creating WNodes

Enhancement

In order to support automatic code splitting for higher order components such as Outlet, it would be useful to support a function that returns a promise of a widget when using w or perhaps an additional API (so not to unnecessarily expose the API to the end user).

Within WidgetBase this function would be registered against an id and added to the registry, the function would then be replaced by the id on subsequent renders and the rest of the processing would flow through the usual registry path.

Note: it would only be able to support functions that don't change across renders so the function could not be defined inline, such as () => imports('./mywidget')

Add support in Promise for 'finally' method

@dasa commented on Wed Jan 24 2018

Enhancement

Add support in Promise for finally method since it has now reached stage 4.

Related Issue: dojo/shim#21 (comment)

Convert `Outlet` to use a render prop to describe the output

Enhancement

An Outlet is a basic higher order component which accepts one or more widgets on creation of the outlet.

// separate outlet component file

export const MyOutlet = Outlet({
    index: IndexWidget, 
    main: MainWidget, 
    error: ErrorWidget }, 'outlet-name'):

The current implementation is problematic for typings when there are multiple widgets specified as the Outlet's properties becomes a union type of all the widget's properties passed to the Outlet. This is not correct, as you may need to pass different values for the same property depending on the match type scenario. Another side affect means that widgets could receive extra properties that were intended for a different widget.

There are at least a couple of potential options:

Option 1

Move from a HOC to a component that accepts a render property to describe the outlets output. This will allow consumers to explicitly pass the properties to each of the widgets and give more control to the consumer to create customised logic on which widgets to display.

// inside your widget
render() {
    return v('div', [
        w(Outlet, { 
            to: 'outlet-name', 
            renderer: (matchDetails) => {
                // match details contains the `matchType`, `params` and `queryParams`
                return w(MyWidget, { foo: 'bar', id: matchDetails.id });
            }
        })
    ]);
}

Options 2

Keep with a HOC to a component but one that accepts a render function to describe the outlets output. This will also allow consumers to explicitly pass the properties to each of the widgets and give more control to the consumer to create customised logic on which widgets to display.

interface MyOutletProperties {
    foo: string;
}

const MyOutlet = Outlet<MyOutletProperties>((properties, outletProps) => {
     if (outletProps.isError()) {
        return w(ErrorWidget, {});
     }
     if (outletProps.isExact()) {
         return w(ExactMatchWidget, {});
     }

     // return undefined when no widget is needed to be rendered based on the match type.
     return undefined;
}, 
{ outlet: 'foo' })

Write a blog announcing @dojo/framework

Write a dojo.io blog outlining the changes we're making and justifying the move to @dojo/framework

Add `watch` decorator that will invalidate when the property is set

Enhancement

Often widgets contain internal state that, when set, require the user to call this.invalidate() to ensure the widget is re-rendered.

Add a decorator for watching internal properties so that when they are set it will automatically call invalidate

class MyWidget extends WidgetBase {

    @watch()
    private _myState = 0;

    private _increment() {
         this._myState = this._myState + 1; // this automatically calls invalidate
    }

    protected render() {
        return v('div', [ 
            v('button', { onclick: this._increment }, [ 'Increment' ]),
            `${this._myState}`)
        ]);
    }
}

Potential improvements to state management performance, possibly making it pluggable

@maier49 commented on Fri May 11 2018

For large state stores, things like ImmutableJS are recommended by the redux team as a way to improve update performance. On the other hand ImmutableJS can be quite slow for operations like finding a value.

Making the actual state management portion of the store pluggable would allow a user to implement something that suits their needs without making additional assumptions.

Alternatively, or in addition to this, we could look into general performance improvements such as doing updates in a web worker, since we completely control the "reduction" part of the store life cycle.

New Dojo Vdom Rendering Engine

Enhancement

The existing vdom implementation is becoming difficult to maintain, enhance and performance tune due to starting with maquette's vdom and integrating dojo's widget concepts into the existing code base. To enable dojo to continue enhancing the core renderer's functionality and flexibility, a ground up re-design is required. The re-design will provide a backwards compatible solution that ensures both widgets and virtual dom nodes are equal citizens within the engine and enable enhancements such as scheduling to be addressed.

Implementation Tracking

• Basic widget and node diff'ing and rendering
• Basic event handlers
• Basic Render scheduling
• Support returning arrays
• Insert before calculation
• Sub tree rendering and depth ordering
• Registry support
• Support deferred properties
• Auto instance binding for widget and node functions
• SVG Support
• Support changing event handlers across renders
• DOM Merging Support
• Sync Mode
• Node operations (focus, blur, click, scrollIntoView)
• Support dom pragma
• Lifecycle hooks (onAttach, onDetach)
• Advanced Render scheduling
• Exit, enter and update animation support
• No Performance Regressions versus existing vdom
• Passing Unit Tests