-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[doc] Add an ADR to improve React representations rendering #3962
base: master
Are you sure you want to change the base?
Conversation
CHANGELOG.adoc
Outdated
@@ -16,6 +16,8 @@ | |||
- [ADR-154] Add support for finding parent in tree representation | |||
- [ADR-155] Add max-width expression for diagram labels | |||
- [ADR-156] Make it possible to display the semantic elements as a tree in the Selection Dialog | |||
- [ADR-156] Make it possible to display the semantic elements as a tree in the Selection Dialog |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Duplicate of line "ADR-156"
doc/adrs/157_improve_react_component_representations_rendering.adoc
Outdated
Show resolved
Hide resolved
With the actual implementation, when we receive a new payload to update the representation we also update all the components under it. | ||
|
||
|
||
This causes a noticeable impact on performance with representation rendering lots of elements and particularly if they use lots of interactions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what "use lots of interactions" means?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I'll change the phrasing, I wanted to point out representation that have more way to interact with than others (like diagrams)
Signed-off-by: Michaël Charfadi <michael.charfadi@obeosoft.com>
ab5f500
to
3cdca28
Compare
When we want to access a representation we have to subscribe to it. | ||
|
||
|
||
Each time a representation changes, a new payload is sent to the subscribers of this representation. | ||
|
||
|
||
This guarantee that all subscribers of a representation are in synch with the actual data of the representation | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stop putting two empty lines between sentences. A simple line return is enough.
We should start by comparing the payloads when the client receives and update only the revelant React Component. | ||
|
||
Then measure the performance improvements before trying a more complex approach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can understand in the grand scheme of things how we could use a solution like that but I don't see what would motive it right now.
The changes sended by the back-end could look like the changes used by the
ReactFlow renderer
meaning for the nodes
That would be a massive change in itself. While it would certainly help with minor operations like moving a node, most of what is possible in a diagram has a sizable impact, potentially changing dozens of elements in a diagram. I'm not even sure that "computing the incremental change" would be faster than just sending the new diagram. I'm not sure which performance problem identified RIGHT NOW you would solve with this.
Our approach to performance improvements will be guided by concrete performance problems identified right now. This ADR involves multiples massive architectural changes on both the backend and the frontend of multiple parts of the code. It may make some good points but it's way too vague and generic.
If you want to move forward with such proposal, when you will have time affected to performance improvement or during a cool down:
- Find and measure a specific performance problem that affects our end users
- Come up with an ADR to solve that specific problem
We could move forward one day with incremental changes sent over the subscription for representations, we could move forward with other kind of changes for tree based representations too but in this state, I don't understand what clear issue this ADR is trying to solve and how it would solve it. The constraints we have one tree based representations and diagram or form based representations are very different and the solution would have to be tailor made for each use case. I feel that this document should probably be 2 or 3 different ADRs but I don't clearly see the performance issue identified for each use case.
Pull request template
General purpose
What is the main goal of this pull request?
Project management
priority:
andpr:
labels been added to the pull request? (In case of doubt, start with the labelspriority: low
andpr: to review later
)area:
,difficulty:
,type:
)CHANGELOG.adoc
been updated to reference the relevant issues?CHANGELOG.adoc
? (Including changes in the GraphQL API)CHANGELOG.adoc
? For example indoc/screenshots/2022.5.0-my-new-feature.png
Architectural decision records (ADR)
[doc]
?CHANGELOG.adoc
?Dependencies
CHANGELOG.adoc
?CHANGELOG.adoc
?Frontend
This section is not relevant if your contribution does not come with changes to the frontend.
General purpose
Typing
We need to improve the typing of our code, as such, we require every contribution to come with proper TypeScript typing for both changes contributing new files and those modifying existing files.
Please ensure that the following statements are true for each file created or modified (this may require you to improve code outside of your contribution).
useMutation<DATA_TYPE, VARIABLE_TYPE>(…)
useQuery<DATA_TYPE, VARIABLE_TYPE>(…)
useSubscription<DATA_TYPE, VARIABLE_TYPE>(…)
useMachine<CONTEXT_TYPE, EVENTS_TYPE>(…)
useState<STATE_TYPE>(…)
?.
(if the GraphQL API specifies that a field cannot benull
, do not treat it has potentiallynull
for example)let diagram: Diagram | null = null;
)Backend
This section is not relevant if your contribution does not come with changes to the backend.
General purpose
Architecture
Review
How to test this PR?
Please describe here the various use cases to test this pull request