Skip to content
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

internals: setState api and efficient render updates #90

Open
toloudis opened this issue Jan 30, 2023 · 3 comments
Open

internals: setState api and efficient render updates #90

toloudis opened this issue Jan 30, 2023 · 3 comments
Assignees

Comments

@toloudis
Copy link
Contributor

toloudis commented Jan 30, 2023

Use Case

As a developer, the public api is too spread out over many functions that have partial side effects.
We would like to be able to update large chunks of state with only one function call.

Solution

Copy the data structure from allen-cell-animated/website-3d-cell-viewer#110 down into volume-viewer and export it.
Partially implement the react-like state update mechanism as discussed in Teams call in volume-viewer, starting only with VolumeOptions (our temporary name for the appearance and channel editing information).
We believe this can be implemented at low technical risk as an alternate code path that doesn't modify any of the other public api or internal Drawable classes.
After some nontrivial tbd amount of functionality is in, we can assess the impact on performance and code maintainability/readability.

The end goal which may require followup issues is to have all settings updated via this mechanism and remove the individual setters in the api. A requirement for the final goal will be to have good documentation of the whole data structure and a clear path forward for future modifications.

@toloudis
Copy link
Contributor Author

@frasercl can you paste in the quick chunk of code you wrote so we have it here for reference?

@toloudis
Copy link
Contributor Author

see #123 also, somewhat related

@frasercl
Copy link
Collaborator

Very closely related to #159, to the extent that it might be useful to attack both these issues together in a single refactoring effort

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

No branches or pull requests

3 participants