@zenuml/core 3.47.9 → 3.48.1

package/docs/responsive-participant-margin.md

@@ -1,52 +0,0 @@
-This is to adjust the margin of the lifelines based on the message length.
-For example, if the message is long, the margin of the lifelines will be increased.
-
-A.method() {
-B.aLongMethodName_and_we_want_to_adjust_the_margin_of_the_lifelines_based_on_the_message_length();
-}
-
-# Strategy A
-
-Step 1. We need to know the width of the method box is shorter than the
-width of the message label. We only need to compare the scrollWidth and the width.
-
-# Strategy B
-
-Instead of rendering message layer based on lifeline's position, we render
-the lifelines based on message occurrence's positions.
-
-There is a problem of this strategy. If we pre-declare the order of the participants,
-for example, `B A A.method()`, we have to render B on the left of A.
-
-So maybe, we could implement it in two rounds. First, we define the order of participants.
-Then we calculate the position of the lifelines based on the order.
-
-Note that `mounted` is only called when we "mount" the element,
-not when we "move" or "relayout" the element.
-
-When we change the code, it may NOT trigger mounted. It may not even
-trigger the update of Occurrence.
-
-We cannot just clear the stored positions, because we will have no other chance
-to refresh the positions again. So another option is to refresh the positions
-when we after mounted and/or updated MessageLayer.
-
-It looks promising now. The current challenge is to render lifelines
-according to the positions of participants. A particularly interesting part
-is participant group. We may need to render it on a different layer.
-
-Strategy B relies on the browser's behavior on 'width: auto'. So we need
-to know when we should set it as auto. Pre-assign positions is in conflict
-of this approach, unless we could tell whether it is pre-assigned or not.
-
-What if we always set interaction width to auto first and then update according
-to calculated positions?
-
-One of the most tricky part is when a message is removed. To make sure we know
-the gap between two participants, we need to know the width of message. However,
-if the message is removed, we need to clear the gap we saved because of this message.
-This is particularly trick because we may not receive a message for it. Vue may not
-destroy the message but just trigger an update and render a different message on it.
-
-In the new try, we will try to generate the positions based on antlr root context
-and two width providers - message width provider and participant width provider.

package/docs/starter.md

@@ -1,9 +0,0 @@
-There are two ways for the context to get declared Starter:
-
-1. @Starter(X)
-2. X->A:m or X->A.m
-
-As long as the starter's name is not \_STARTER\_, it is treated as declared.
-
-Then we check whether the Starter is a declared participant by its `explicit`
-field.