#1010 Colormaker-constructor #1011
Conversation
Previous implementation of Colormaker was probably relying on JS prototypal inheritance. Colormaker cannot be called like a function anymore. (cherry picked from commit 0899733)
There was a problem hiding this comment.
That is a little strange, and surprising why the existing classical (explicit prototype) method fails, but switching to the class syntax reads more clearly anyway.
I take it this works with:
a. Regular built-in colorschemes (uniform etc)
b. Colorschemes added by a user which implement atomColor etc
c. Selection colorschemes?
If so then all looks good to me.
|
@fredludlow I've made some further tests and, noticed that one of my projects, it breaks the Typescrip checks. If I ignore the checks, the code works well though. 
I'll investigate further. |
One type of argument was missing, as `scheme` can have 2 shapes (either a class derived from Colormaker or a function that redefines the Colormaker prototype on a derived class). It was necessary to add type predicates to correctly infer the type of `scheme` within the addScheme method.
|
Issue resolved: it was a missing typescript definition for the argument of the |
I am wondering if that's not an issue with terser, which can turn |
This PR fixes issue #1010 where the syntax for registering a ColorMaker does not generate valid JS.
After bissection, I've found out that this issue has been introduced with the recent changes to the build process (PR #993). It's possible that the transpilation + bundling results in invalid JS code (?).
The fix was already done in the update-three,js ongoing branch, and had been cherry-picked from there.