Update README Content #701

agubler · 2017-10-02T11:58:19Z

Type: bug

The following has been addressed in the PR:

There is a related issue
All code matches the style guide
Unit or Functional tests are included in the PR

Description:

Add sections for

beforeProperties
Registry
Container/Injectors

Resolves #669
Resolves #671

… injectors

dylans

Minor nits, grammar and typo fixes, and a few suggestions for improved clarity.

dylans · 2017-10-02T16:34:23Z

README.md

+
+The `Registry` provides a mechanism to define widgets and injectors (see the [`Containers & Injectors`](#containers--injectors) section), that can be dynamically/lazily loaded on request. Once the registry widget is loaded all widgets that need the newly loaded widget will be invalidated and re-rendered automatically.
+
+A main registry can be provided to the `projector`, which will be automatically passed to all widgets within the tree (referred to as `baseRegistry`). Each widget also gets a access to a private `Registry` instance that can be used to define widget specific registry items. The locally defined registry items are considered a higher precedence than an item registered in the `baseRegistry`.


gets a access -> gets access

widget specific registry -> widget-specific registry

dylans · 2017-10-02T16:35:24Z

README.md

+projector.setProperties({ registry });
+```
+
+In some scenarios, it might be desirable to allow the `baseRegistry` override the an item defined in the local `registry`. To do this use pass `true` as the second argument of the `registry.get` function.


baseRegistry override the an item -> baseRegistry to override an item

dylans · 2017-10-02T16:36:16Z

README.md

+projector.setProperties({ registry });
+```
+
+In some scenarios, it might be desirable to allow the `baseRegistry` override the an item defined in the local `registry`. To do this use pass `true` as the second argument of the `registry.get` function.


To do this use pass true as the second argument of the registry.get function. -> Use true as the second argument of the registry.get function to override the local item.

dylans · 2017-10-02T16:36:54Z

README.md

+
+In some scenarios, it might be desirable to allow the `baseRegistry` override the an item defined in the local `registry`. To do this use pass `true` as the second argument of the `registry.get` function.
+
+The following example, sets a default loading indicator widget but passes `true` when getting the widget from the `registry`. This allows a consumer to register an overriding loading indicator in the `baseRegistry`.


example, sets a default loading indicator widget but -> example sets a default loading indicator widget, but

dylans · 2017-10-02T16:37:41Z

README.md


-TODO: Section
+Occasionally, in a mixin or a widget class, it my be required to provide logic that needs to be executed before properties are diffed (`beforeProperties`) or either side `render` call (`beforeRender` & `afterRender`). This functionality is provided by the `beforeProperties`, `beforeRender` and `afterRender` decorators that can be found in the `decorators` directory.


"or either side render call" feels like a word is missing

dylans · 2017-10-02T16:46:35Z

README.md

    }
 }
 ```

+**Please Note:** Don't use container as the top level application widget, containers always `render` which means that you'll find your application is calling `render` every request animation frame even if there is no need for the `render`.


Don't -> Do not
you'll -> you will
calling render every request animation frame even if there is no need for the render. -> calling render upon every request animation frame, even when there is no need for an additional render.

dylans · 2017-10-02T16:46:55Z

README.md

+
+### Decorators
+
+All built-in decorators can be used in non-decorator environments (Either JavaScript/ES6 or a TypeScript project that does not have the experimental decorators configuration set to true in the `tsconfig`) programmatically calling them directly, usually within a Widget classes `constructor`.


we use builtin, built in, and built-in, we should decide on one and be consistent

dylans · 2017-10-02T16:47:17Z

README.md

+
+### Decorators
+
+All built-in decorators can be used in non-decorator environments (Either JavaScript/ES6 or a TypeScript project that does not have the experimental decorators configuration set to true in the `tsconfig`) programmatically calling them directly, usually within a Widget classes `constructor`.


programmatically calling -> programmatically by calling

dylans · 2017-10-02T16:47:39Z

README.md

+
+### Decorators
+
+All built-in decorators can be used in non-decorator environments (Either JavaScript/ES6 or a TypeScript project that does not have the experimental decorators configuration set to true in the `tsconfig`) programmatically calling them directly, usually within a Widget classes `constructor`.


Widget classes -> either Widget class' or Widget class ?

dylans · 2017-10-02T16:47:56Z

README.md

@@ -619,7 +710,7 @@ The currently supported options:
 |-|-|
 |`onAttached`|A callback that is called when the wrapped DOM is flowed into the virtual DOM|

-For example, if we want to integrate a 3rd party library where we need to pass the component factory a _root_ element and then flow that into our virtual DOM.  In this situation we don't want to create the component until the widget is being flowed into the DOM, so `onAttached` is used to perform the creation of the component:
+For example, if we want to integrate a 3rd party library where we need to pass the component factory a _root_ element and then flow that into our virtual DOM.  In this situation we do not want to create the component until the widget is being flowed into the DOM, so `onAttached` is used to perform the creation of the component:


3rd party -> third-party

agubler · 2017-10-02T21:48:49Z

Thanks for the review @dylans feedback addressed (i think)

dylans

one typo, after that this is good to merge

dylans · 2017-10-03T03:47:00Z

README.md

@@ -535,7 +535,7 @@ class MyWidget extends WidgetBase {

 The `Registry` provides a mechanism to define widgets and injectors (see the [`Containers & Injectors`](#containers--injectors) section), that can be dynamically/lazily loaded on request. Once the registry widget is loaded all widgets that need the newly loaded widget will be invalidated and re-rendered automatically.

-A main registry can be provided to the `projector`, which will be automatically passed to all widgets within the tree (referred to as `baseRegistry`). Each widget also gets a access to a private `Registry` instance that can be used to define widget specific registry items. The locally defined registry items are considered a higher precedence than an item registered in the `baseRegistry`.
+A main registry can be provided to the `projector`, which will be automatically passed to all widgets within the tree (referred to as `baseRegistry`). Each widget also gets access to a private `Registry` instance that can be used to define registry items the are scoped to the widget. The locally defined registry items are considered a higher precedence than an item registered in the `baseRegistry`.


the are scoped -> that are scoped

agubler added 2 commits October 2, 2017 12:55

Add some readme content for missing sections, registries, containers,…

a2ca0a8

… injectors

typo

94cfa15

agubler requested a review from dylans October 2, 2017 11:58

agubler added 2 commits October 2, 2017 13:03

remove superfluous types and close code block

e840288

few small changes [skip ci]

f276edf

agubler requested review from kitsonk and rorticus October 2, 2017 12:27

dylans suggested changes Oct 2, 2017

View reviewed changes

dylans added this to the 2017.10 milestone Oct 2, 2017

Address feedback

e30aa75

dylans approved these changes Oct 3, 2017

View reviewed changes

kitsonk approved these changes Oct 3, 2017

View reviewed changes

rorticus approved these changes Oct 3, 2017

View reviewed changes

matt-gadd approved these changes Oct 3, 2017

View reviewed changes

typo

8d81218

agubler merged commit fa44745 into dojo:master Oct 3, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update README Content #701

Update README Content #701

agubler commented Oct 2, 2017

dylans left a comment

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

dylans Oct 2, 2017

agubler commented Oct 2, 2017

dylans left a comment

dylans Oct 3, 2017


		The `Registry` provides a mechanism to define widgets and injectors (see the [`Containers & Injectors`](#containers--injectors) section), that can be dynamically/lazily loaded on request. Once the registry widget is loaded all widgets that need the newly loaded widget will be invalidated and re-rendered automatically.

		A main registry can be provided to the `projector`, which will be automatically passed to all widgets within the tree (referred to as `baseRegistry`). Each widget also gets a access to a private `Registry` instance that can be used to define widget specific registry items. The locally defined registry items are considered a higher precedence than an item registered in the `baseRegistry`.


		In some scenarios, it might be desirable to allow the `baseRegistry` override the an item defined in the local `registry`. To do this use pass `true` as the second argument of the `registry.get` function.

		The following example, sets a default loading indicator widget but passes `true` when getting the widget from the `registry`. This allows a consumer to register an overriding loading indicator in the `baseRegistry`.


		TODO: Section
		Occasionally, in a mixin or a widget class, it my be required to provide logic that needs to be executed before properties are diffed (`beforeProperties`) or either side `render` call (`beforeRender` & `afterRender`). This functionality is provided by the `beforeProperties`, `beforeRender` and `afterRender` decorators that can be found in the `decorators` directory.


		### Decorators

		All built-in decorators can be used in non-decorator environments (Either JavaScript/ES6 or a TypeScript project that does not have the experimental decorators configuration set to true in the `tsconfig`) programmatically calling them directly, usually within a Widget classes `constructor`.

Update README Content #701

Update README Content #701

Conversation

agubler commented Oct 2, 2017

dylans left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agubler commented Oct 2, 2017

dylans left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment