You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think there are two major improvements that can be made to the configuration immediately and relatively easily.
The first is to make all properties of the ViewerConfigOptions type required, and create a second ViewerConstructorOptions that includes the optional and overloaded versions. As an example, ViewerConfigOptions would have:
That would preserve the overloaded behavior offered to the consumer, while removing the need for a massive amount of ?. chaining and typecasting throughout the rest of the code. The Constructor version would be coerced into the standard Config version on init, and it would always reliably be there.
The other thing, which goes hand in hand with that one, would be to take any configuration provided by the consumer and deep merge it with the default configuration instead of relying on the consumer to pass in a full config or making every piece of a code that uses a particular option have its own guards.
These two changes would greatly simplify the project as a whole, and make type checking more reliable for both internal components and consumers.
The text was updated successfully, but these errors were encountered:
Expanding on this comment:
I think there are two major improvements that can be made to the configuration immediately and relatively easily.
The first is to make all properties of the
ViewerConfigOptions
type required, and create a secondViewerConstructorOptions
that includes the optional and overloaded versions. As an example,ViewerConfigOptions
would have:while
ViewerConstructorOptions
would have:That would preserve the overloaded behavior offered to the consumer, while removing the need for a massive amount of
?.
chaining and typecasting throughout the rest of the code. TheConstructor
version would be coerced into the standardConfig
version on init, and it would always reliably be there.The other thing, which goes hand in hand with that one, would be to take any configuration provided by the consumer and deep merge it with the default configuration instead of relying on the consumer to pass in a full config or making every piece of a code that uses a particular option have its own guards.
These two changes would greatly simplify the project as a whole, and make type checking more reliable for both internal components and consumers.
The text was updated successfully, but these errors were encountered: