Skip to content

Loading Components: Sum-up

Details of blocking in blocking stages

Blocking Messages will be used by the component core class when loading or destroying a component. In the initialization phase a blocking message will be used as splash message or in case of an error an error message will be displayed.

So you have to pay attention if you load a component into a blocking layer to avoid recursive blocking.

We have learned how to load CenteredMessage and Hint components into blocking layers. These two components have all splash screens by default disabled.

There are a total of four splash modules. If you want to disable splash screens of a component you can set the following namespaced options:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
"@codecoupler": {
  component: {
    splash: {
      init: false,
      start: false,
      destroy: false,
      error: false
    }
  }
}

Details of Main Stage

We want to explain a little detail of the main stage of a widget or canvas. As we have learned every component have a main stage. So also a widget or canvas component.

What are we learning here?

  • Some details of the main stage of a widget

What we also learned is that into a stage we can load any further components. We have loaded applications into the level foreground, messages into the level block and error and hints into the level hint.

This leads to the question if we can load a component into the level base in the main stage of a widget or canvas.

Let's sketch how the structure of a widget or canvas roughly looks like:

┌───────────────────────────────┐
│ Main Stage                    │
│ And outer frame DOM node      │
│┌─────────────────────────────┐│
││ Component Element           ││
││ Accesible over this.element ││
│└─────────────────────────────┘│
└───────────────────────────────┘

Loading an application into the main stage (as we have done already) will be loaded by default into the level foreground. Components in this stage level do not collide with the "component element" because they are created in a separate DOM node.

Therefore they will not intercept with the compoment element. (likewise, no other component collides with the in the stage level background would be loaded).

But if you try to load a widget or canvas based component into the main stage of a widget or canvas, it would use the level base and this would collide with the component element. And this leads to an error.

You can of course load any component into another level. That would work. For example you could load a canvas based component into the level background. That would make sense. In any case, it makes no sense loading a widget or canvas based component into the level foreground.

Parallel Blocking

If you have many parallel tasks which blocks and unblocks a component in a unpredictible manner you can use two strategies:

  1. Every task store its own component which was loaded into the blocking layer and remove this component if ready.
  2. All tasks use the same blocking component and refresh just the message.

The second strategy is much more efficient, but you have to pay attention to some details.

  1. First of all you have to set always the same id for the blocking component. This can be realized with the load method await this.load("root", CenteredMessage, { text: "..." }, Id) or with the third argument of the helper method await this.block(Type, Message, Id). Multiple parallel loads will be handled correctly.
  2. To destroy the message try to get the component and destroy if exists with this.getStage("root").getComponent(Id)?.destroy() or with the helper method this.unblock(Id). Multiple parallel destroying and destroying of components that are not yet initialized will be handled correctly.
  3. You should use await when crating a block component. It could happen that you unblock a component before the blocking was ready. In this case the blocking will stay. Normally you do not have to wait for unblocking or destroying functions.