-
-
Notifications
You must be signed in to change notification settings - Fork 214
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
Reconsider usage of accessor properties #349
Comments
I'll copy the middle in here for reference:
good examples could be threejs, or the dom, they strike a sensible balance between atomics and more complex functions that will either carry out calculations or set multiple props at once. the upside for atomics is that they can easily by driven by state models and spread over the surface. another upside is maintenance for abstractions of pp. if pp updates and introduces a new atomic, say we are also publishing types for raw postprocessing, https://github.com/pmndrs/react-postprocessing/blob/master/types/postprocessing.d.ts that would be another "abstraction" that's currently quite simple to adjust. |
That sounds reasonable. One motivation behind the move towards methods was that a lot of settings on effects need to trigger shader recompilations to take effect. Using method calls makes it clear that changes will be expensive as opposed to just changing the value of a seemingly harmless property. |
Getter and setter methods have been converted into accessor properties in |
Is your feature request related to a problem?
Recent API refactoring replaced accessor properties and plain properties with methods. This will inadvertently increase the maintenance burden for maintainers of
react-posprocessing
if left as-is.Describe the solution you'd like
Reconsider using a hybrid approach of methods and accessors properties if applicable.
Additional context
#279 (comment)
The text was updated successfully, but these errors were encountered: