Skip to content
This repository has been archived by the owner on Jul 19, 2020. It is now read-only.

Add a diagram of the component lifecycle #22

Open
jstarry opened this issue Feb 9, 2020 · 6 comments
Open

Add a diagram of the component lifecycle #22

jstarry opened this issue Feb 9, 2020 · 6 comments

Comments

@jstarry
Copy link
Member

jstarry commented Feb 9, 2020

Something like:

Render Cycle

  1. create()
  2. view()
  3. (yew renders to page)
  4. mounted()

Note: should explain how children components are rendered... (Parent view -> Child view -> Child mount -> Parent mount)

Update Cycle

  1. (trigger event / callback / send message)
  2. update()
  3. (optional) view()
  4. (yew renders to page)

Change Cycle

  1. (render component with new props)
  2. update()
  3. (optional) view()
  4. (yew renders to page)

DOC TODO: https://yew.rs/docs/concepts/components#lifecycle

@connor4312
Copy link

connor4312 commented Feb 28, 2020

I would be happy to help with this. How do you think we should generate graphs? Something that's worked for me in the past is having graphviz .dot files (e.g.) and makefiles or other build task that render those--makes them easy to edit/diff with no special software. Thoughts?

@jstarry
Copy link
Member Author

jstarry commented Feb 28, 2020

@connor4312 thanks for your interest in helping out! Yeah, that's basically what I had in mind 👍

@teymour-aldridge
Copy link
Contributor

@connor4312 Do you plan on implementing this? I'd be happy to do it otherwise!

@rlasjunies
Copy link

@jstarry
Here are 2 proposals using the same tool as the one of the Agent lifecycle.
Let us know what is your feeling.

@teymour-aldridge fyi

All in one

image

General lifecycle

image

Change and Update lifecycle

image

The nomnoml code I've used for these diag

rendering done with a vscode plugin to render it in markdown

[Create]->[View]
[View]->[Rendered]
[Rendered]->[...]
[...]->[Update cycle]
[...]->[Change cycle]

[...]->[Destroy]
[Update cycle]->[...]
[Change cycle]->[...]

[Update cycle|update is called bla bla bla|
  [Update]->[<choice>Should render?]
  [<choice>Should render?]->false[<end>e]
  [<choice>Should render?]->true[view]
]

[Change cycle|change is called bla bla bla|
  [Change]->[<choice>Should render?]
  [<choice>Should render?]->false[<end>e]
  [<choice>Should render?]->true[view]
]
[Create]->[View]
[View]->[Rendered]
[Rendered]->[...]
[...]->[Update cycle]
[...]->[Change cycle]

[Update cycle|update is called bla bla bla|
  [Update]->[<choice>Should render?]
  [<choice>Should render?]->false[<end>e]
  [<choice>Should render?]->true[view]
]

[Change cycle|change is called bla bla bla|
  [Change]->[<choice>Should render?]
  [<choice>Should render?]->false[<end>e]
  [<choice>Should render?]->true[view]
]

[...]->[Destroy]
[Update cycle]->[...]
[Change cycle]->[...]

@teymour-aldridge
Copy link
Contributor

teymour-aldridge commented May 10, 2020 via email

@rlasjunies
Copy link

@teymour-aldridge

  • right for the svg/png ... we will take care for the final version
  • I do agree for the "...", good proposals. I was also thinking to "idle".
  • "Update"/"Change" cycle ... I reused the initial text proposal. Anyway I did not found a better way to express this "loop".

I shared the nomnoml code to accelarate the collaboration. Do not hesitate to update the proposals.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants