Shulou(Shulou.com)06/03 Report--

This article mainly introduces how to use Dojo components, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

The basic principles of components

Widgets are the basic building blocks of all Dojo applications. Widgets are the main encapsulation units that represent everything from a single element of the user interface to higher-level container elements such as Form forms, paragraphs, pages, and even complete applications.

Preface: reduce complexity

A single part usually represents a single responsibility in an application. Subtle responsibilities are naturally transformed into separate components, while complex responsibilities need to be split into several interdependent parts. Each part can then be implemented as a widget, in which one or more parent container parts coordinate the interaction of all disassembled parts. In this hierarchy, you can see that the root component achieves greater responsibility as a whole, but in fact it is achieved by combining many simple components.

For a complete application, all of its requirements set is a single, complex responsibility. Implementing this complete set of requirements using Dojo results in hierarchical components, usually starting with the "Application" part of the root node, then spending layers of components according to each layer of function, and finally reaching the leaf node that represents a single element in the HTML page.

The benefits of simplicity

The reasons for keeping components as simple as possible are: for individual parts, reducing complexity means greater separation of responsibilities (narrowing the scope); easier comprehensive testing; fewer opportunities for errors; and more targeted bug fixes; and broader component reuse potential.

At the application level, simple widgets make it easier for us to understand each component and how they fit together.

These benefits simplify day-to-day maintenance and ultimately reduce the overall cost of building and running applications.

Basic component structure

The core of the widget is just a rendering function, which returns the virtual DOM node, which describes the structure of the widget in the web page through the virtual DOM node. However, applications often need to deal with more logic than simply listing HTML elements, so meaningful widgets are often made up of more than simple rendering functions.

Subassemblies are usually located in their respective, separately named TypeScript modules, and each module exports defined subassemblies by default.

The easiest way to represent an assembly is based on a normal function, starting with the factory definition of the rendering function. Dojo's @ dojo/framework/core/vdom module provides a create () function that allows authors to define their own widget rendering function factory. A named render function can be preferred because it helps debugging, but it is not necessary; an assembly can also be identified by an exported variable that holds the factory definition of the assembly.

Dojo also provides class-based widgets for applications that prefer to use class structures rather than functions. This widget inherits the WidgetBase provided in the @ dojo/framework/core/WidgetBase module and must implement a render () method.

The following example shows the parts of a Dojo application that are of no practical use, but are fully functional:

Src/widgets/MyWidget.ts

Function-based Dojo widgets:

Import {create} from'@ dojo/framework/core/vdom';const factory = create (); export default factory (function MyWidget () {return [];})

Class-based Dojo parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';export default class MyWidget extends WidgetBase {protected render () {return [];}}

Because the rendering function of this widget returns an empty array, there is nothing in the output of the application. Widgets typically return one or more virtual DOM nodes to include meaningful structures in the HTML output of the application.

Converting a virtual DOM node to output in a web page is processed by Dojo's rendering system.

Assembly Styl

The style of the DOM output of the widget is handled by CSS, and the related style classes are stored in the CSS module file, which corresponds to the TypeScript module of the widget. Function-based and class-based widgets use the same style. This topic is described in detail in the style and theme reference guide.

Rendering assembly

Dojo is a responsive framework that handles the propagation of data changes and related background update rendering. Dojo uses the concept of virtual DOM (VDOM) to describe the output elements, and nodes in VDOM are simple JavaScript objects designed to improve developer productivity without interacting with actual DOM elements.

Applications only need to be concerned by declaring their desired output structure as hierarchical virtual DOM nodes, usually as the return value of the widget's rendering function. The Renderer component of the framework then synchronizes the desired output to specific elements in the DOM. You can also configure parts and elements and provide state for parts and elements by passing attributes to the virtual DOM node.

Dojo supports rendering of some child nodes of the tree, which means that when the state changes, the framework can locate the corresponding subset of the VDOM nodes affected by the change. Then, only the affected subtrees in the DOM tree are updated to respond to changes, improve rendering performance, and improve the user's interactive experience.

Note: the virtual node returned in the assembly rendering function is the only factor that affects application rendering. Trying to use any other practice is considered anti-pattern in Dojo application development and should be avoided.

Support for TSX

Dojo supports the use of jsx syntax extensions, which is called tsx in TypeScript. This syntax makes it easier to describe the output of VDOM and is closer to HTML in the application you build.

Allow applications that use TSX

You can easily build projects that allow the use of TSX with the dojo create app-- tsx CLI command.

For Dojo projects that are not built in this way, you can enable TSX by adding the following to the project's TypeScript configuration:

. / tsconfig.json

{"compilerOptions": {"jsx": "react", "jsxFactory": "tsx"}, "include": [. / src/**/*.ts ",". / src/**/*.tsx ",". / tests/**/*.ts ",". / tests/**/*.tsx "]} TSX part example

For subassemblies with a .tsx file extension, to output TSX in the render function, simply import the tsx function in the @ dojo/framework/core/vdom module:

Src/widgets/MyTsxWidget.tsx

Function-based widgets:

Import {create, tsx} from'@ dojo/framework/core/vdom';const factory = create (); export default factory (function MyTsxWidget () {return Hello from a TSX widgets;})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {tsx} from'@ dojo/framework/core/vdom';export default class MyTsxWidget extends WidgetBase {protected render () {return Hello from a TSX widgets;}}

If the widget needs to return multiple top-level TSX nodes, you can wrap them in container elements. This is clearer than returning an array of nodes because it supports a more natural automatic formatting of TSX code blocks. As follows:

Src/widgets/MyTsxWidget.tsx

Function-based widgets:

Import {create, tsx} from'@ dojo/framework/core/vdom';const factory = create (); export default factory (function MyTsxWidget () {return (First top-level widget element Second top-level widget element);}); use VDOMVDOM node type

Dojo identifies two types of nodes in VDOM:

VNode, or Virtual Nodes, is a virtual representation of specific DOM elements as the lowest-level rendered output of all Dojo applications.

WNode, or Widget Nodes, associates Dojo parts to the hierarchy of VDOM.

In the virtual node of Dojo, both VNode and WNode can be regarded as subtypes of DNode, but applications usually do not deal with DNode at the abstract level. The TSX syntax is recommended because it renders two types of virtual nodes in a uniform syntax.

Instantiate VDOM nodes

If you don't want to use TSX, you can import the v () or w () functions in the @ dojo/framework/core/vdom module in the widget. They create VNode and WNode, respectively, and can be used as part of the value returned by the assembly rendering function. Their signatures, abstractly, are as follows:

V (tagName | VNode, properties?, children?):

W (Widget | constructor, properties, children?)

Parameter optional description tagName | VNode No usually, tagName is passed in the form of a string that corresponds to the tag signature of the corresponding DOM element that VNode will render. If VNode is passed in, the newly created VNode will be a copy of the original VNode. If the properties parameter is passed in, duplicate attributes in the properties are merged and applied to the copy VNode. If the children parameter is passed in, all child nodes in the original VNode will be completely overwritten in the new copy. Widget | constructor No usually, Widget is passed, which references the imported widget as a generic type. You can also pass in several types of constructor that allow Dojo to instantiate widgets in a variety of different ways. They support advanced features such as delayed loading. Propertiesv: yes, w: not used to configure the property set of the newly created VDOM node. They also allow the framework to detect whether the node has been updated to re-render. A children is a set of nodes that are rendered as children of a newly created node. If desired, you can also use string literals to represent any text node. Assemblies typically encapsulate their own child nodes, so this parameter is more likely to be used with v () than w (). Virtual node exampl

The following sample widget contains a more representative rendering function that returns a VNode. Its expected structure description is that a simple div DOM element contains a text node:

Src/widgets/MyWidget.ts

Function-based widgets:

Import {create, v} from'@ dojo/framework/core/vdom';const factory = create (); export default factory (function MyWidget () {return v ('div', [' Hello, Dojo']);})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {v} from'@ dojo/framework/core/vdom';export default class MyWidget extends WidgetBase {protected render () {return v ('div', [' Hello, Dojo']);} example of combined parts

Similarly, you can use the w () method to combine subassemblies, or you can mix two types of nodes to output multiple nodes to form a more complex hierarchy:

Src/widgets/MyComposingWidget.ts

Function-based widgets:

Import {create, v, w} from'@ dojo/framework/core/vdom';const factory = create (); import MyWidget from'. / MyWidget';export default factory (function MyComposingWidget () {return v ('div', [' This widget outputs several virtual nodes in a hierarchy', w (MyWidget, {})]);})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {v, w} from'@ dojo/framework/core/vdom';import MyWidget from'. / MyWidget';export default class MyComposingWidget extends WidgetBase {protected render () {return v ('div', [' This widget outputs several virtual nodes in a hierarchy', w (MyWidget, {})]);} render to DOM

Dojo provides a rendering factory function renderer () for the application, which is exported by the @ dojo/framework/core/vdom module by default. The factory function provided defines the root node of the application, where the output of the VDOM structure is inserted.

The application typically calls the renderer () function at the main entry point (main.tsx/main.ts), and then mounts the returned Renderer object on the DOM element specified in the application's HTML page. If no element is specified when mounting the application, it is mounted under document.body by default.

For example:

Src/main.tsx

Import renderer, {tsx} from'@ dojo/framework/core/vdom';import MyComposingWidget from'. / widgets/MyComposingWidget';const r = renderer (() = >); r.mount (); MountOptions attribute

The Renderer.mount () method receives an optional parameter, MountOptions, which is used to configure how the mount operation is performed.

Attribute type optional description syncboolean is the default: false. If true, the relevant callbacks in the rendering lifecycle (especially the after and deferred rendering callback functions) are run synchronously. If false, the callback function is scheduled to run asynchronously until the next redrawing of window.requestAnimationFrame (). In rare cases, running the render callback function synchronously can be useful when a specific node needs to exist in DOM, but this mode is not recommended for most applications. DomNodeHTMLElement is the specified DOM element, and the render result of the VDOM is inserted into the DOM node. If not specified, it defaults to document.body. RegistryRegistry is an optional Registry instance that can be used between mounted VDOM.

For example, mount a Dojo application to a specified DOM element instead of under document.body:

Src/index.html

This div is outside the mounted Dojo application. This div contains the mounted Dojo application.

Src/main.tsx

Import renderer, {tsx} from'@ dojo/framework/core/vdom';import MyComposingWidget from'. / widgets/MyComposingWidget';const dojoAppRootElement = document.getElementById ('my-dojo-app') | | undefined;const r = renderer (() = >); r.mount ({domNode: dojoAppRootElement}); add an external DOM node to the VDOM

Dojo can wrap external DOM elements and effectively introduce them into the application's VDOM as part of the rendered output. This is done through the dom () tool method in the @ dojo/framework/core/vdom module. It works like v (), but its main parameter uses an existing DOM node instead of an element tag string. When VNode is returned, it references the DOM node passed to it instead of using the newly created element v ().

Once the VNode returned by dom () is added to the application's VDOM, the Dojo application actually takes ownership of the wrapped DOM node. Note that this procedure applies only to external nodes of Dojo applications, such as siblings of mounted application elements, or newly created nodes that are disconnected from the DOM of the main web page. If the wrapped node is the ancestor or descendant node of the element on which the application is mounted, it will be invalid.

Dom () API

Dom ({node, attrs = {}, props = {}, on = {}, diffType = 'none', onAttach})

Parameter optional describes whether node is added to the Dojo VDOM external DOM node attrs is applied to the external DOM node HTML attribute (attributes) props is attached to the DOM node (properties) on is applied to the external DOM node event collection diffType is default: none. Change the detection policy to determine whether the Dojo application needs to update the external DOM node onAttach is an optional callback function that detects changes in the external DOM node after the node is appended to the DOM

External nodes added by dom () are removed from regular virtual DOM nodes because they may be processed outside of the Dojo application. This means that Dojo cannot primarily use VNode attributes to set the state of an element, but must rely on the JavaScript attribute (properties) and HTML attribute (attributes) of the DOM node itself.

Dom () receives the diffType attribute, allowing the user to specify a property change detection policy for the wrapped node. A specified policy indicates how to use the wrapped node to help Dojo determine whether the JavaScript and HTML properties have changed, and then apply the change to the wrapped DOM node. The default strategy is none, which means that Dojo only needs to add wrapped DOM elements to the application output in each rendering cycle.

Note: all strategies use events from the previous VNode to ensure that they are correctly deleted and applied to each rendering.

Available dom () change detection strategies:

DiffType describes none this mode passes in empty objects for the previous attributes and properties of the wrapped VNode, meaning that the props and attrs passed to dom () are reapplied to the wrapped node in each rendering cycle. Dom this mode compares the attributes and properties in the DOM node with the props and attrs passed in dom () to determine if there are differences, and then applies those differences. Vdom this mode is compared with the previous VNODE, which is actually the default VDOM difference comparison strategy for Dojo. Any changes made directly to the wrapped node are ignored when change detection and update rendering. Configure the widget through properties

The concept of properties passed to the nodes in VDOM is the core pillar of Dojo. Node attributes act as the primary conduit for propagating state in the application, either from the parent part to the child part or layer by layer through the event handler. They can also serve as an important API for the user to interact with the widget, passing properties to the parent widget to configure its DOM structure (returning VNode) or passing it to the child widget it manages (returning WNode).

VNode receives properties of type VNodeProperties, and WNode receives a minimum of WidgetProperties. The author of the widget usually defines his own property interface and then requires the caller to pass in the interface.

Key of the VDOM node

Widgetproperties is very simple and contains only one optional attribute, key, which also exists in VNodeProperties.

When the widget starts outputting multiple elements at the same level of VDOM and of the same type, key must be specified. For example, if a list part manages multiple list items, you need to specify a key for each item in the list.

When you re-render the affected part of the VDOM, the Dojo uses the key of the virtual node to uniquely identify the specific instance. If key is not used to distinguish multiple nodes of the same type in the same level in VDOM, Dojo cannot determine exactly which child nodes are affected by failure changes (invalidating change).

Note: the key of the virtual node should be consistent in multiple calls to the render function. In each rendering call, generating a different key for the same output node is considered anti-pattern in Dojo application development and should be avoided.

Configure VNode

VNodeProperties contains many fields and is an important API for interacting with elements in DOM. Many of these properties mirror the properties available in HTMLElement, including event handlers that specify various oneventname.

These attributes of the application are unidirectional because Dojo applies a given set of attributes to a specific DOM element, but does not synchronize any subsequent changes to the corresponding DOM attribute to VNodeProperties. Any such changes should be passed back to the Dojo application through the event handler. When the event handler is called, the application can handle any state changes required by the event, update the corresponding VNodeProperties view when the VDOM structure is output for rendering, and then the Renderer of Dojo synchronizes all relevant DOM updates.

Modify attributes and difference detection

Dojo uses the attributes of the virtual node to determine whether a given node has been updated and therefore needs to be re-rendered. Specifically, it uses a difference detection strategy to compare the property sets of the previous and current rendered frames. If a difference is detected in the latest attribute set received by a node, the node is invalidated and re-rendered in the next drawing cycle.

Note: property change detection is managed internally by the framework and depends on the VDOM output structure declared in the assembly's rendering function. Attempts to retain references to attributes and modify them outside the normal assembly rendering cycle are considered anti-pattern in Dojo application development and should be avoided.

Support for interactive event listeners

When you instantiate a node, you assign event listeners to the virtual node in the same way as you specify any other property. When you output VNode, the name of the event listener on VNodeProperties is mirrored to the equivalent event of HTMLElement. Although authors of custom widgets can name events according to their choice, they usually follow a similar onEventName naming convention.

Function properties, such as event handlers, are automatically bound to the this context of the widget that instantiates this virtual node. However, if a bound function is passed to an attribute value, it will not be repeatedly bound to this.

Dealing with focus

When you output a VNode, the widget can use the focus attribute of the VNodeProperties to control whether the generated DOM element gets focus at render time. This is a special property that can receive an object of type boolean or return a function of type boolean.

When true is passed directly, the element gets focus only if the previous value is not true (similar to regular property change detection). When you pass in a function, the element gets focus as long as the function returns true, regardless of the last return value.

For example:

Depending on the order of the elements, the "firstFocus" input box below only gets focus when you initialize the rendering, while the "subsequentFocus" input box gets focus each time you render, because the value of the focus attribute is a function.

Src/widgets/FocusExample.tsx

Function-based widgets:

Import {create, tsx, invalidator} from'@ dojo/framework/core/vdom';const factory = create ({invalidator}); export default factory (function FocusExample ({middleware: {invalidator}}) {return (true} / > invalidator ()} > Re-render);})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {tsx} from'@ dojo/framework/core/vdom';export default class FocusExample extends WidgetBase {protected render () {return (true} / > this.invalidate ()} > Re-render);}} delegate focus

A function-based assembly can use focus middleware to set the focus for its child assembly or accept focus from the parent assembly. Class-based widgets can delegate focus in the same way using FocusMixin (from @ dojo/framework/core/mixins/Focus).

FocusMixin adds a this.shouldFocus () method to the widget's class, while function-based widgets use the focus.shouldFocus () middleware method to achieve the same purpose. This method checks whether the widget is in a state where this.focus () is executed, and only returns true for a single call until the widget's this.focus () method is called again (the function-based widget uses the equivalent focus.focus ()).

FocusMixin or focus middleware also adds a focus function attribute to the API of the widget. The frame uses the Boolean results of this property to determine whether the subassembly (or one of its subassemblies) should gain focus when rendering. Typically, an assembly passes shouldFocus methods to a specific subassembly or output node through its focus property, allowing the parent assembly to delegate focus to its subassembly.

For an example of a function-based part, see the focus middleware delegation example in the Dojo Middleware reference Guide

The following class-based assembly example shows the focus of delegation and control within the assembly hierarchy and between the output VNode:

Src/widgets/FocusableWidget.tsx

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {tsx} from'@ dojo/framework/core/vdom';import Focus from'@ dojo/framework/core/mixins/Focus';interface FocusInputChildProperties {onFocus: () = > void } class FocusInputChild extends Focus (WidgetBase) {protected render () {/ * The child widget's `this.shouldFocus () `method is assigned directly to the input node's `focus` property, allowing focus to be delegated from a higher level containing parent widget. The input's `onfocus () `event handler is also assigned to a method passed in from a parent widget, allowing user-driven focus changes to propagate back into the application. * / return;}} export default class FocusableWidget extends Focus (WidgetBase) {private currentlyFocusedKey = 0; private childCount = 5; private onFocus (key: number) {this.currentlyFocusedKey = key; this.invalidate ();} / * Calling `this.focus () `resets the widget so that `this.shouldFocus () `will return true when it is next invoked. * / private focusPreviousChild () {--this.currentlyFocusedKey; if (this.currentlyFocusedKey

< 0) { this.currentlyFocusedKey = this.childCount - 1; } this.focus(); } private focusNextChild() { ++this.currentlyFocusedKey; if (this.currentlyFocusedKey === this.childCount) { this.currentlyFocusedKey = 0; } this.focus(); } protected render() { /* The parent widget's `this.shouldFocus()` method is passed to the relevant child element that requires focus, based on the simple previous/next widget selection logic. This allows focus to be delegated to a specific child node based on higher-level logic in a container/parent widget. */ return ( Previous Next this.onFocus(0)} />

This.onFocus (1)} / > this.onFocus (2)} / > this.onFocus (3)} / > this.onFocus (4)} / >);}} state management

In simple applications where data does not need to flow between multiple components, state management is very simple. The data needed by the part can be encapsulated in the part, which is the most basic form of state management in Dojo applications.

As applications become more complex and require data to be shared and transferred between multiple parts, a more robust form of state management is needed. Here, Dojo begins to demonstrate the value of its responsive framework, allowing applications to define how data flows between components, which then manages change detection and re-rendering. This is done by connecting the widget to the attributes when declaring the VDOM output in the widget's render function.

State management can be one of the most challenging tasks for large applications, requiring developers to strike a balance between data consistency, availability, and fault tolerance. While most of this complexity is beyond the scope of the web application layer, Dojo provides a further solution to ensure data consistency. The Dojo Store component provides a centralized state store that provides a consistent API for accessing and managing data from multiple locations in the application.

Basics: self-packaged assembly statu

An assembly can maintain its internal state in a variety of ways. Function-based parts can use cache or icache middleware to store the local state of parts, while class-based parts can use internal class fields.

The internal state data may directly affect the rendered output of the subassembly, or it may be passed to the subassembly as attributes, which in turn directly affect the rendered output of the subassembly. The widget may also allow its internal state to be changed, such as responding to user interaction events.

The following example explains these patterns:

Src/widgets/MyEncapsulatedStateWidget.tsx

Function-based widgets:

Import {create, tsx} from'@ dojo/framework/core/vdom';import cache from'@ dojo/framework/core/middleware/cache';const factory = create ({cache}) Export default factory (function MyEncapsulatedStateWidget ({middleware: {cache}}) {return (Current widget state: {cache.get ('myState') | |' Hello from a stateful widget'} {let counter = cache.get ('counter') | | 0; let myState =' State change iteration #'+ + counter Cache.set ('myState', myState); cache.set (' counter', counter);} > Change State);})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {tsx} from'@ dojo/framework/core/vdom';export default class MyEncapsulatedStateWidget extends WidgetBase {private myState = 'Hello from a stateful widget packages; private counter = 0 Protected render () {return (Current widget state: {this.myState} {this.myState = 'State change iteration #' + + this.counter > Change State);}}

Note that this example is incomplete, and clicking the "Change State" button does not affect the rendered output of the widget in a running application. This is because the state is fully encapsulated in the MyEncapsulatedStateWidget part, and Dojo has no way of knowing any changes to the part. The framework only handles the initial rendering of the subassembly.

To tell Dojo to re-render, the parts that need to encapsulate the rendering state fail on their own.

Invalidate the parts

Function-based components can use icache middleware to handle local state management and automatically fail the part when the state is updated. Icache combines cache and invalidator middleware, and has the function of cache to deal with the state management of components, and the function of invalidator to invalidate parts when the state changes. Function-based widgets can also use invalidator directly if needed.

For class-based parts, there are two ways to fail:

Explicitly call this.invalidate () at the appropriate location after the state has been changed

In the MyEncapsulatedStateWidget example, this can be done in the onclick handler of the Change State button.

Annotate any relevant fields using the @ watch () decorator (from the @ dojo/framework/core/vdomercorators/watch module). When the @ watch annotated fields are modified, this.invalidate () is implicitly called, which is useful for status fields, which always need to be re-rendered when updated.

Note: marking a subassembly as invalid does not immediately re-render the subassembly, but notifies Dojo that the subassembly is already in the dirty state and should be updated and re-rendered in the next rendering cycle. This means that multiple failures of the same part within the same rendered frame will not adversely affect the performance of the application, but excessive repeated failures should be avoided to ensure optimal performance.

The following is an example of a modified MyEncapsulatedStateWidget that updates the output correctly when the state changes.

Function-based widgets:

Import {create, tsx} from'@ dojo/framework/core/vdom';import icache from'@ dojo/framework/core/middleware/icache';const factory = create ({icache}) Export default factory (function MyEncapsulatedStateWidget ({middleware: {icache}}) {return (Current widget state: {icache.getOrSet ('myState',' Hello from a stateful widget')} {let counter = icache.get ('counter') | | 0; let myState =' State change iteration #'+ + counter Icache.set ('myState', myState); icache.set (' counter', counter);} > Change State);})

Class-based parts:

Here, both myState and counter are updated in the same place as the application logic, so you can add @ watch () to either field or both, and the actual results and performance of these configurations are exactly the same:

Src/widgets/MyEncapsulatedStateWidget.tsx

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import watch from'@ dojo/framework/core/decorators/watch';import {tsx} from'@ dojo/framework/core/vdom';export default class MyEncapsulatedStateWidget extends WidgetBase {private myState: string = 'Hello from a stateful widget packages; @ watch () private counter: number = 0 Protected render () {return (Current widget state: {this.myState} {this.myState = 'State change iteration #' + + this.counter }} > Change State);}} Intermediate: incoming part properties

Passing state to the widget through the properties of the virtual node is the most effective way to connect responsive data streams in Dojo applications.

The widget specifies its own property interface, which contains any fields that the widget wants to expose to the consumer, including configuration options, fields that represent the injection status, and any event handlers.

A function-based widget passes its property interface to create (). Properties () as a generic parameter. Then, the factory function returned by this call chain makes the property values available through the properties function parameters in the render function definition.

A class-based part can define its property interface as a generic parameter of WidgetBase in the class definition, and then access its properties through the this.properties object.

For example, a widget that supports state and event handler properties:

Src/widgets/MyWidget.tsx

Function-based widgets:

Import {create, tsx} from'@ dojo/framework/core/vdom';import icache from'@ dojo/framework/core/middleware/icache';const factory = create (). Properties (); export default factory (function MyWidget ({middleware: {icache}, properties}) {const {name, onNameChange} = properties (); let newName = icache.get ('new-name') | |'; return (Hello, {name}! Not you? Set your name: {icache.set ('new-name', (e.target as HTMLInputElement) .value);}} / > {icache.set (' new-name', undefined); onNameChange & & onNameChange (newName) }} > Set new name);})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {tsx} from'@ dojo/framework/core/vdom';export interface MyWidgetProperties {name: string; onNameChange? (newName: string): void;} export default class MyWidget extends WidgetBase {private newName ='; protected render () {const {name, onNameChange} = this.properties; return (Hello, {name}! Not you? Set your name: {this.newName = (e.target as HTMLInputElement) .value; this.invalidate ();}} / > {this.newName =''; onNameChange & & onNameChange (newName) > Set new name);}}

Users of this sample widget can interact with it by passing in the appropriate properties:

Src/widgets/NameHandler.tsx

Function-based widgets:

Import {create, tsx} from'@ dojo/framework/core/vdom';import icache from'@ dojo/framework/core/middleware/icache';import MyWidget from'. / MyWidget';const factory = create ({icache}); export default factory (function NameHandler ({middleware: {icache}}) {let currentName = icache.get ('current-name') |' Alice'; return ({icache.set ('current-name', newName) } / >);})

Class-based parts:

Import WidgetBase from'@ dojo/framework/core/WidgetBase';import {tsx} from'@ dojo/framework/core/vdom';import watch from'@ dojo/framework/core/decorators/watch';import MyWidget from'. / MyWidget';export default class NameHandler extends WidgetBase {@ watch () private currentName: string = 'Alice'; protected render () {return ({this.currentName = newName) }} / >);}} Advanced: extraction and injection status

When implementing complex functions, following the state encapsulation mode within the component may cause the component to expand and difficult to manage. Another problem can also arise in large applications, where hundreds of parts are grouped together across dozens of levels. It is usually the leaf part that uses state data, not an intermediate container in the VDOM hierarchy. Allowing data state to penetrate such a hierarchical complex component requires the addition of fragile and unnecessary code.

The Store component provided by Dojo solves these problems by extracting state management into a dedicated context and then injecting relevant states from the application into specific parts.

Best development practices

When working with Dojo parts, you should keep some important principles in mind to avoid introducing anti-patterns into your application code. Attempts to use the framework in an unsupported manner can lead to unexpected behavior and introduce hard-to-find errors in the application.

Assembly Properti

The widget should only read the attributes passed in (properties).

If you modify the property values in the incoming assembly, you cannot pass it back to the frame to avoid causing differences between the assembly and the frame.

Widgets should avoid deriving further render state from their properties, and instead rely on their complete render state being provided to them.

Deriving render state can cause similar divergences between the widget and the framework as modifying received properties; the framework is not aware of the derived state, so cannot properly determine when a widget has been updated and requires invalidation and re-rendering.

If necessary, the internal or private state can be completely encapsulated in the assembly.

Implementing "pure" widgets is a valid and often desirable pattern that has no side effects and receives all their states with properties, but this is not the only pattern for developing Dojo widgets.

Use class-based widgets

The _ _ render__, _ _ setProperties__, and _ _ setChildren__ function belongs to the internal implementation details of the framework and is never allowed to be called or overridden in an application.

The application should not instantiate the widget directly-- Dojo fully takes over the lifecycle of the widget instance, including instantiation, caching, and destruction.

Virtual DOM

The key of the virtual node should be consistent in multiple render calls.

If you specify a different key in each rendering call, Dojo cannot effectively associate the previous rendering with the same node in this rendering. Dojo treats the new key that you did not see in the last rendering as a new element, which results in the removal of the previous node from the DOM and the addition of a new set, even if the attributes have not changed, there is no need to update the DOM.

A common anti-pattern is to assign a randomly generated ID (such as GUID or UUID) to the node's key in the assembly's render function. The key value of a node should not be generated in the render function unless the generation strategy is idempotent.

Applications should not store references to virtual nodes for subsequent operations after they are returned from the subassembly's render functions, nor should they attempt to optimize memory allocation by using a single instance across multiple render calls.

Virtual nodes are designed to be lightweight, and the overhead of instantiating a new version in each assembly rendering cycle is very low.

The framework relies on two separate virtual node instances in two assembly render function calls to perform accurate change detection. If no changes are detected, there is no further overhead, rendering, and so on.

Render to DOM

Applications should not use imperative DOM operation calls.

The framework handles all specific rendering responsibilities and provides an alternative mechanism for widget authors to use various DOM features in a simpler, type-safe, and responsive manner.

Thank you for reading this article carefully. I hope the article "how to use Dojo components" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.