@lightningjs/blits 1.30.1 → 1.30.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.editorconfig +7 -7
- package/.eslintignore +1 -1
- package/.eslintrc.cjs +65 -65
- package/.github/workflows/comment-lint-results.yml +124 -124
- package/.github/workflows/comment-test-results.yml +108 -108
- package/.github/workflows/deploy-docs.yml +27 -27
- package/.github/workflows/run-blits-tests.yml +141 -141
- package/.github/workflows/run-lint.yml +127 -127
- package/.husky/pre-commit +1 -1
- package/.vscode/extensions.json +7 -7
- package/.vscode/settings.json +9 -9
- package/CHANGELOG.md +1019 -1012
- package/COPYING +1 -0
- package/LICENSE +202 -202
- package/NOTICE +12 -12
- package/README.md +33 -33
- package/bin/index.js +8 -8
- package/blits.d.ts +6 -6
- package/docs/README.md +19 -19
- package/docs/_sidebar.md +37 -37
- package/docs/built-in/directives.md +50 -50
- package/docs/built-in/for-loop.md +203 -203
- package/docs/built-in/layout.md +168 -168
- package/docs/components/component_state.md +90 -90
- package/docs/components/computed_properties.md +45 -45
- package/docs/components/lifecycle_events.md +42 -42
- package/docs/components/methods.md +45 -45
- package/docs/components/props.md +56 -56
- package/docs/components/user_input.md +186 -186
- package/docs/components/utility_methods.md +320 -320
- package/docs/components/watchers.md +34 -34
- package/docs/essentials/application_root.md +19 -19
- package/docs/essentials/components.md +68 -68
- package/docs/essentials/displaying_images.md +67 -67
- package/docs/essentials/displaying_text.md +135 -135
- package/docs/essentials/element_attributes.md +195 -195
- package/docs/essentials/settings.md +117 -117
- package/docs/essentials/template_syntax.md +83 -83
- package/docs/getting_started/file_structure.md +58 -58
- package/docs/getting_started/getting_started.md +45 -45
- package/docs/getting_started/intro.md +20 -20
- package/docs/index.html +47 -47
- package/docs/performance/lazy-loading.md +161 -161
- package/docs/plugins/global_app_state.md +98 -98
- package/docs/plugins/language.md +172 -172
- package/docs/plugins/text-to-speech-announcer.md +119 -119
- package/docs/plugins/theme.md +176 -176
- package/docs/router/basics.md +175 -175
- package/docs/router/hooks.md +70 -70
- package/docs/router/transitions.md +146 -146
- package/docs/sidebar.json +171 -171
- package/docs/transitions_animations/transitions.md +150 -150
- package/index.d.ts +1099 -1099
- package/index.js +28 -28
- package/jsconfig.json +12 -12
- package/package.json +56 -56
- package/public/assets/fps_sprite.base64.js +1 -1
- package/scripts/postpublish.js +59 -59
- package/scripts/prepublishOnly.js +84 -84
- package/scripts/prepush.js +78 -78
- package/src/announcer/announcer.js +162 -162
- package/src/announcer/speechSynthesis.js +107 -107
- package/src/application.js +100 -100
- package/src/component/base/announcer.js +27 -27
- package/src/component/base/events.js +69 -69
- package/src/component/base/index.js +33 -33
- package/src/component/base/methods.js +244 -244
- package/src/component/base/router.js +41 -41
- package/src/component/base/timeouts_intervals.js +99 -99
- package/src/component/base/utils.js +72 -72
- package/src/component/setup/computed.js +48 -48
- package/src/component/setup/index.js +62 -62
- package/src/component/setup/input.js +30 -30
- package/src/component/setup/methods.js +37 -37
- package/src/component/setup/props.js +62 -62
- package/src/component/setup/props.test.js +238 -238
- package/src/component/setup/routes.js +42 -42
- package/src/component/setup/state.js +59 -59
- package/src/component/setup/watch.js +35 -35
- package/src/component.js +437 -437
- package/src/component.test.js +388 -388
- package/src/components/Circle.js +73 -73
- package/src/components/Circle.orig.js +31 -31
- package/src/components/FPScounter.js +1510 -1510
- package/src/components/FPScounter.orig.js +121 -121
- package/src/components/RouterView.js +81 -81
- package/src/components/RouterView.orig.js +54 -54
- package/src/components/Sprite.js +94 -94
- package/src/components/Sprite.orig.js +58 -58
- package/src/components/index.js +28 -28
- package/src/components/index.orig.js +28 -28
- package/src/constants.js +21 -21
- package/src/engine.js +1 -1
- package/src/engines/L3/element.js +744 -744
- package/src/engines/L3/element.test.js +579 -579
- package/src/engines/L3/fontLoader.js +38 -38
- package/src/engines/L3/index.js +7 -7
- package/src/engines/L3/launch.js +123 -123
- package/src/engines/L3/shaderLoader.js +12 -12
- package/src/engines/index.js +1 -1
- package/src/focus.js +90 -90
- package/src/helpers/deepEqualArray.js +50 -50
- package/src/helpers/deepEqualArray.test.js +127 -127
- package/src/helpers/fetchJson.js +34 -34
- package/src/helpers/sequence.js +26 -26
- package/src/launch.js +123 -123
- package/src/lib/blitsfileconverter/blitsfileconverter.js +52 -52
- package/src/lib/codegenerator/generator.js +788 -788
- package/src/lib/codegenerator/generator.test.js +3801 -3801
- package/src/lib/colors/colors.js +92 -92
- package/src/lib/colors/colors.test.js +290 -290
- package/src/lib/colors/htmlColors.js +168 -168
- package/src/lib/componentId.js +49 -49
- package/src/lib/componentId.test.js +84 -84
- package/src/lib/eventListeners.js +123 -123
- package/src/lib/eventListeners.test.js +236 -236
- package/src/lib/hooks.js +59 -59
- package/src/lib/lifecycle.js +85 -85
- package/src/lib/log.js +117 -117
- package/src/lib/precompiler/precompiler.js +73 -73
- package/src/lib/reactivity/effect.js +93 -93
- package/src/lib/reactivity/effect.test.js +35 -35
- package/src/lib/reactivity/reactive.js +208 -208
- package/src/lib/reactivity/reactive.test.js +27 -27
- package/src/lib/reactivityguard/computedprops.js +218 -218
- package/src/lib/symbols.js +108 -108
- package/src/lib/templateparser/parser.js +386 -386
- package/src/lib/templateparser/parser.test.js +1411 -1411
- package/src/lib/utils.js +27 -27
- package/src/plugin.js +27 -27
- package/src/plugins/appstate.js +26 -26
- package/src/plugins/index.js +20 -20
- package/src/plugins/language.js +152 -152
- package/src/plugins/log.js +25 -25
- package/src/plugins/theme.js +94 -94
- package/src/router/router.js +514 -514
- package/src/router/router.test.js +473 -473
- package/src/router/transitions/fadeIn.js +27 -27
- package/src/router/transitions/fadeInOut.js +33 -33
- package/src/router/transitions/index.js +21 -21
- package/src/router/transitions/slideIn.js +28 -28
- package/src/router/transitions/slideInOut.js +33 -33
- package/src/settings.js +40 -40
- package/vite/blitsFileConverter.js +67 -67
- package/vite/index.js +28 -28
- package/vite/msdfGenerator.js +269 -269
- package/vite/preCompiler.js +42 -42
- package/vite/reactivityGuard.js +45 -45
- package/vscode/data/template-attributes.json +589 -589
|
@@ -1,42 +1,42 @@
|
|
|
1
|
-
# Hooking into Lifecycle Events
|
|
2
|
-
|
|
3
|
-
Blits components follow a defined flow of lifecycle events. You can integrate specific logic into these events by specifying them in the `hooks` key of the Component configuration object.
|
|
4
|
-
|
|
5
|
-
For each available lifecycle event, you can define a function with the same name as the event itself. This function will then execute each time the lifecycle event is triggered for your component's instance. It's essential to use a regular function instead of an arrow function if you intend to access the `this` scope of your component instance.
|
|
6
|
-
|
|
7
|
-
## Lifecycle Events
|
|
8
|
-
|
|
9
|
-
The following lifecycle events are available in Blits components.
|
|
10
|
-
|
|
11
|
-
- **init()**: This event fires when the component is being instantiated, just before it sends its render instructions to the Lightning renderer. At this point, the elements of your template won't be available yet.
|
|
12
|
-
|
|
13
|
-
- **ready()**: The `ready` event fires when the component instance is fully initialized and rendered, indicating that it's ready for interaction.
|
|
14
|
-
|
|
15
|
-
- **focus()**: This event triggers whenever the component instance receives focus. It's important to note that this event can fire multiple times during the component's lifecycle, depending on user interactions.
|
|
16
|
-
|
|
17
|
-
- **unfocus()**: The `unfocus` event fires whenever the component instance loses focus. Similar to the `focus` event, it can occur multiple times during the component's lifecycle.
|
|
18
|
-
|
|
19
|
-
- **destroy()**: The `destroy` event fires when the component is being destroyed and removed. This event provides an opportunity to perform any custom cleanup operations before the component is removed.
|
|
20
|
-
|
|
21
|
-
```js
|
|
22
|
-
export default Blits.Component('MyComponent', {
|
|
23
|
-
// ...
|
|
24
|
-
hooks: {
|
|
25
|
-
init() {
|
|
26
|
-
// Logic to execute on init event
|
|
27
|
-
},
|
|
28
|
-
ready() {
|
|
29
|
-
// Logic to execute on ready event
|
|
30
|
-
},
|
|
31
|
-
focus() {
|
|
32
|
-
// Logic to execute on focus event
|
|
33
|
-
},
|
|
34
|
-
unfocus() {
|
|
35
|
-
// Logic to execute on unfocus event
|
|
36
|
-
},
|
|
37
|
-
destroy() {
|
|
38
|
-
// Logic to execute on destroy event
|
|
39
|
-
},
|
|
40
|
-
},
|
|
41
|
-
})
|
|
42
|
-
```
|
|
1
|
+
# Hooking into Lifecycle Events
|
|
2
|
+
|
|
3
|
+
Blits components follow a defined flow of lifecycle events. You can integrate specific logic into these events by specifying them in the `hooks` key of the Component configuration object.
|
|
4
|
+
|
|
5
|
+
For each available lifecycle event, you can define a function with the same name as the event itself. This function will then execute each time the lifecycle event is triggered for your component's instance. It's essential to use a regular function instead of an arrow function if you intend to access the `this` scope of your component instance.
|
|
6
|
+
|
|
7
|
+
## Lifecycle Events
|
|
8
|
+
|
|
9
|
+
The following lifecycle events are available in Blits components.
|
|
10
|
+
|
|
11
|
+
- **init()**: This event fires when the component is being instantiated, just before it sends its render instructions to the Lightning renderer. At this point, the elements of your template won't be available yet.
|
|
12
|
+
|
|
13
|
+
- **ready()**: The `ready` event fires when the component instance is fully initialized and rendered, indicating that it's ready for interaction.
|
|
14
|
+
|
|
15
|
+
- **focus()**: This event triggers whenever the component instance receives focus. It's important to note that this event can fire multiple times during the component's lifecycle, depending on user interactions.
|
|
16
|
+
|
|
17
|
+
- **unfocus()**: The `unfocus` event fires whenever the component instance loses focus. Similar to the `focus` event, it can occur multiple times during the component's lifecycle.
|
|
18
|
+
|
|
19
|
+
- **destroy()**: The `destroy` event fires when the component is being destroyed and removed. This event provides an opportunity to perform any custom cleanup operations before the component is removed.
|
|
20
|
+
|
|
21
|
+
```js
|
|
22
|
+
export default Blits.Component('MyComponent', {
|
|
23
|
+
// ...
|
|
24
|
+
hooks: {
|
|
25
|
+
init() {
|
|
26
|
+
// Logic to execute on init event
|
|
27
|
+
},
|
|
28
|
+
ready() {
|
|
29
|
+
// Logic to execute on ready event
|
|
30
|
+
},
|
|
31
|
+
focus() {
|
|
32
|
+
// Logic to execute on focus event
|
|
33
|
+
},
|
|
34
|
+
unfocus() {
|
|
35
|
+
// Logic to execute on unfocus event
|
|
36
|
+
},
|
|
37
|
+
destroy() {
|
|
38
|
+
// Logic to execute on destroy event
|
|
39
|
+
},
|
|
40
|
+
},
|
|
41
|
+
})
|
|
42
|
+
```
|
|
@@ -1,45 +1,45 @@
|
|
|
1
|
-
# Methods
|
|
2
|
-
|
|
3
|
-
Within a Blits component, you have quite some freedom where to put specific logic.
|
|
4
|
-
|
|
5
|
-
Template related logic can be either placed directly in a _reactive / interpolated_ attribute or you can move it out to a _computed property_ if the logic is more complex.
|
|
6
|
-
|
|
7
|
-
Business logic for your App can be placed directly in a _watcher_, a _lifecycle hook_ or an _input handling_ function.
|
|
8
|
-
|
|
9
|
-
If you notice that you're duplicating logic in these different places, or if you just like to keep all your business logic nicely grouped together, you can move these business logic functions under the `methods` key of the _Component configuration object_.
|
|
10
|
-
|
|
11
|
-
You can reference your Component's methods in the template by using a `$`-sign (for example in the `@loaded`-attribute when your element has a `src` attribute).
|
|
12
|
-
|
|
13
|
-
In the javascript code of a Component, you can reference methods directly on the `this`-scope (i.e. `this.getData()`). Similar to `internal` state and `props`, there is no need to prefix with `methods`, for easy access.
|
|
14
|
-
|
|
15
|
-
```js
|
|
16
|
-
export default Blits.Component('Carousel', {
|
|
17
|
-
template: `
|
|
18
|
-
<Element>
|
|
19
|
-
<!-- .... -->
|
|
20
|
-
</Element>
|
|
21
|
-
`,
|
|
22
|
-
state() {
|
|
23
|
-
return {
|
|
24
|
-
items: [],
|
|
25
|
-
page: 0
|
|
26
|
-
}
|
|
27
|
-
},
|
|
28
|
-
hooks: {
|
|
29
|
-
ready() {
|
|
30
|
-
this.fetchData()
|
|
31
|
-
}
|
|
32
|
-
},
|
|
33
|
-
input: {
|
|
34
|
-
down() {
|
|
35
|
-
this.page++
|
|
36
|
-
this.fetchData()
|
|
37
|
-
}
|
|
38
|
-
},
|
|
39
|
-
methods: {
|
|
40
|
-
async fetchData() {
|
|
41
|
-
this.items = await API.get(['movies', 'tvshows', 'documentaries'], this.page)
|
|
42
|
-
},
|
|
43
|
-
}
|
|
44
|
-
})
|
|
45
|
-
```
|
|
1
|
+
# Methods
|
|
2
|
+
|
|
3
|
+
Within a Blits component, you have quite some freedom where to put specific logic.
|
|
4
|
+
|
|
5
|
+
Template related logic can be either placed directly in a _reactive / interpolated_ attribute or you can move it out to a _computed property_ if the logic is more complex.
|
|
6
|
+
|
|
7
|
+
Business logic for your App can be placed directly in a _watcher_, a _lifecycle hook_ or an _input handling_ function.
|
|
8
|
+
|
|
9
|
+
If you notice that you're duplicating logic in these different places, or if you just like to keep all your business logic nicely grouped together, you can move these business logic functions under the `methods` key of the _Component configuration object_.
|
|
10
|
+
|
|
11
|
+
You can reference your Component's methods in the template by using a `$`-sign (for example in the `@loaded`-attribute when your element has a `src` attribute).
|
|
12
|
+
|
|
13
|
+
In the javascript code of a Component, you can reference methods directly on the `this`-scope (i.e. `this.getData()`). Similar to `internal` state and `props`, there is no need to prefix with `methods`, for easy access.
|
|
14
|
+
|
|
15
|
+
```js
|
|
16
|
+
export default Blits.Component('Carousel', {
|
|
17
|
+
template: `
|
|
18
|
+
<Element>
|
|
19
|
+
<!-- .... -->
|
|
20
|
+
</Element>
|
|
21
|
+
`,
|
|
22
|
+
state() {
|
|
23
|
+
return {
|
|
24
|
+
items: [],
|
|
25
|
+
page: 0
|
|
26
|
+
}
|
|
27
|
+
},
|
|
28
|
+
hooks: {
|
|
29
|
+
ready() {
|
|
30
|
+
this.fetchData()
|
|
31
|
+
}
|
|
32
|
+
},
|
|
33
|
+
input: {
|
|
34
|
+
down() {
|
|
35
|
+
this.page++
|
|
36
|
+
this.fetchData()
|
|
37
|
+
}
|
|
38
|
+
},
|
|
39
|
+
methods: {
|
|
40
|
+
async fetchData() {
|
|
41
|
+
this.items = await API.get(['movies', 'tvshows', 'documentaries'], this.page)
|
|
42
|
+
},
|
|
43
|
+
}
|
|
44
|
+
})
|
|
45
|
+
```
|
package/docs/components/props.md
CHANGED
|
@@ -1,56 +1,56 @@
|
|
|
1
|
-
# Props
|
|
2
|
-
|
|
3
|
-
Components in Blits have their own [internal state](./component_state.md) and logic, and as such a Component is self-contained. However, as each component is part of a larger App scope, they may need to display different behaviors or appearances based on the rest of the app.
|
|
4
|
-
|
|
5
|
-
To achieve this, components can receive `props` from their parent component.
|
|
6
|
-
|
|
7
|
-
## Defining and passing props
|
|
8
|
-
|
|
9
|
-
In the Component configuration object, you can specify exactly which props a component accepts. These props are passed to the component via attributes in the parent component's template. Any attributes that are not explicitly defined as a prop will be ignored.
|
|
10
|
-
|
|
11
|
-
The `props` key in the Component configuration object should be an `Array`, where each item corresponds to a prop that the component can accept.
|
|
12
|
-
|
|
13
|
-
The simplest way to define props is to just list their names within the `props` array:
|
|
14
|
-
|
|
15
|
-
```js
|
|
16
|
-
{
|
|
17
|
-
props: ['x', 'color', 'index', 'alpha']
|
|
18
|
-
}
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
Once specified, you can refer to these props inside the template of your component using the `$` sign, similar to how you would reference variables defined within the component's [internal state](./component_state.md) (i.e. `<Element color="$color" />`).
|
|
22
|
-
|
|
23
|
-
You can also access a prop inside a component's code using `this.color` (without a dollar sign!). And similar to component `state` variables,
|
|
24
|
-
there is no need to specifically reference the `props`-key. Blits automatically maps all props directly on the `this`-scope, for easy access.
|
|
25
|
-
|
|
26
|
-
Since props are used to pass information from a parent to a child, it's important not to attempt to _modify_ props inside your child component. If changes based on the prop from the parent are needed, you should probably use the prop in a so called [computed property](./computed_properties.md).
|
|
27
|
-
|
|
28
|
-
## Advanced usage
|
|
29
|
-
|
|
30
|
-
For more advanced usage, you can define props using an array with an `object` for each prop, instead of just a string with the accepted name. Within each prop object, you can:
|
|
31
|
-
|
|
32
|
-
- Specify a _default value_ for the prop if it's omitted.
|
|
33
|
-
- _Validate_ the value of the prop based on certain criteria.
|
|
34
|
-
- Mark the prop as _required_.
|
|
35
|
-
- Apply a `cast` function to modify the value passed as a prop.
|
|
36
|
-
|
|
37
|
-
As you can see in the following example, you can mix and match the simple string notation with the advanced object notation within the same `props` array.
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
```js
|
|
41
|
-
export default Blits.Component('MyComponent', {
|
|
42
|
-
// ...
|
|
43
|
-
props: [
|
|
44
|
-
'color',
|
|
45
|
-
{
|
|
46
|
-
key: 'alpha',
|
|
47
|
-
default: 0.5,
|
|
48
|
-
required: true,
|
|
49
|
-
validate(v) {
|
|
50
|
-
return v <= 1 && v >= 0;
|
|
51
|
-
},
|
|
52
|
-
cast: Number
|
|
53
|
-
}
|
|
54
|
-
]
|
|
55
|
-
})
|
|
56
|
-
```
|
|
1
|
+
# Props
|
|
2
|
+
|
|
3
|
+
Components in Blits have their own [internal state](./component_state.md) and logic, and as such a Component is self-contained. However, as each component is part of a larger App scope, they may need to display different behaviors or appearances based on the rest of the app.
|
|
4
|
+
|
|
5
|
+
To achieve this, components can receive `props` from their parent component.
|
|
6
|
+
|
|
7
|
+
## Defining and passing props
|
|
8
|
+
|
|
9
|
+
In the Component configuration object, you can specify exactly which props a component accepts. These props are passed to the component via attributes in the parent component's template. Any attributes that are not explicitly defined as a prop will be ignored.
|
|
10
|
+
|
|
11
|
+
The `props` key in the Component configuration object should be an `Array`, where each item corresponds to a prop that the component can accept.
|
|
12
|
+
|
|
13
|
+
The simplest way to define props is to just list their names within the `props` array:
|
|
14
|
+
|
|
15
|
+
```js
|
|
16
|
+
{
|
|
17
|
+
props: ['x', 'color', 'index', 'alpha']
|
|
18
|
+
}
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
Once specified, you can refer to these props inside the template of your component using the `$` sign, similar to how you would reference variables defined within the component's [internal state](./component_state.md) (i.e. `<Element color="$color" />`).
|
|
22
|
+
|
|
23
|
+
You can also access a prop inside a component's code using `this.color` (without a dollar sign!). And similar to component `state` variables,
|
|
24
|
+
there is no need to specifically reference the `props`-key. Blits automatically maps all props directly on the `this`-scope, for easy access.
|
|
25
|
+
|
|
26
|
+
Since props are used to pass information from a parent to a child, it's important not to attempt to _modify_ props inside your child component. If changes based on the prop from the parent are needed, you should probably use the prop in a so called [computed property](./computed_properties.md).
|
|
27
|
+
|
|
28
|
+
## Advanced usage
|
|
29
|
+
|
|
30
|
+
For more advanced usage, you can define props using an array with an `object` for each prop, instead of just a string with the accepted name. Within each prop object, you can:
|
|
31
|
+
|
|
32
|
+
- Specify a _default value_ for the prop if it's omitted.
|
|
33
|
+
- _Validate_ the value of the prop based on certain criteria.
|
|
34
|
+
- Mark the prop as _required_.
|
|
35
|
+
- Apply a `cast` function to modify the value passed as a prop.
|
|
36
|
+
|
|
37
|
+
As you can see in the following example, you can mix and match the simple string notation with the advanced object notation within the same `props` array.
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
```js
|
|
41
|
+
export default Blits.Component('MyComponent', {
|
|
42
|
+
// ...
|
|
43
|
+
props: [
|
|
44
|
+
'color',
|
|
45
|
+
{
|
|
46
|
+
key: 'alpha',
|
|
47
|
+
default: 0.5,
|
|
48
|
+
required: true,
|
|
49
|
+
validate(v) {
|
|
50
|
+
return v <= 1 && v >= 0;
|
|
51
|
+
},
|
|
52
|
+
cast: Number
|
|
53
|
+
}
|
|
54
|
+
]
|
|
55
|
+
})
|
|
56
|
+
```
|