Consider afterUpdate call after conntected

[lukas-schardt]

I think the initial rendering is kind of an update too and calling afterUpdate would make sense. Code that is needed in afterUpdate is most likely needed after the initial render too.

By calling afterUpdate after connected, we would not need to write duplicate code, needed in afterUpdate and connected.

A solution could be to call the afterUpdate hook manually in our BaseElement after calling the connected hook.

[quarkus]

+1 i think it could be a good compromise to keep the default hooks silent during the first update an manually call the "afterUpdate" right after the initial connected.

@eddyloewen as i am writing this .. i think we had to discuss the exact timing of when the the property watch callbacks (before / or after update) are getting triggered correct?

[eddyloewen]

+1 on the afterUpdate being called right after connected. Maybe we should have a meeting together and discuss the final design for it.

@quarkus I think the watchers are another/different topic that we should discuss separately. But yeah! I would like to talk about them as well.

[eddyloewen]

For some reason I just thought about this again. To still have the option to do something different on the first afterUpdate call, we could pass it an options object with a boolean flag to indicate the first update.

afterUpdate({ firstUpdate }) {
  if (!firstUpdate) {
    //do something
  }
}

[eddyloewen]

Let's forget about the { firstUdpate } option for now... While implementing #60 I remembered why it was not so easy to do it right from the beginning... The actual first afterUpdate would be called BEFORE the connected hook. That was the problem. So everything will stay the same for now. But I have added a manual call to afterUpdate right after the connected hook just like @lukas-schardt suggested.

[eddyloewen]

This has been resolved with #60 and will be fixed with the v1.0.0 release