search

Arokip / flutter_diagram_editor

Fllutter diagram editor library
MIT License
116 stars 38 forks source link

Override/extend ComponentData/CanvasModelWriter/ComponentWriter behavior #35

Closed point-source closed 4 months ago

point-source commented 1 year ago

I have an application where properties of a parent component's children determine properties of the parent. For instance, size and color depend on both how many children there are and what state they are in.

Currently, each time any child changes, I need to trigger a function to iterate through all children and recalculate the parent. As more components get added and potentially infinitely nested, this becomes a performance issue. I could maintain a separate cache of this data but then I need to manually keep it synced.

I would like to be able to change the way children are handled at the ComponentData level. My first thought was to use the custom component data to store children instead of ComponentData but I realized that would require me to be able to override methods from CanvasModelWriter and ComponentWriter such as removeComponentWithChildren() and setComponentParent().

What is the best approach to accomplish this?

I also considered forking the project and stripping out the parent/child and link (and possibly type) features since those feel like they might be more flexible if used as a custom component data implementation. I just wanted to make sure there wasn't a better way before going that deep. In this regard, is there a reason why ComponentData is not a base class to ensure basic methods/getters/setters are available and allowing extension rather than having a user-defined nested custom component data object?

Thanks in advance. This has been a really powerful and fascinating library to work with and I really appreciate all the work that has clearly been put into it.

Arokip commented 1 year ago

is there a reason why ComponentData is not a base class to ensure basic methods/getters/setters are available and allowing extension rather than having a user-defined nested custom component data object?

I don't have an answer to that if I understand you correctly. The package still has flaws that I didn't think about when I was creating it.

I am not sure what to recommend. I've never tried what you are describing.

If you are interested I am willing to make a call with you to discuss your issue and find the best solution for it or propose package changes.

point-source commented 1 year ago

If you are interested I am willing to make a call with you to discuss your issue and find the best solution for it or propose package changes.

Sure thing! I just sent an email to what I hope was your email address :)