I took a look at the internal code, and it’s very picky about what can be in the returned object. If you’ve got anything other than menuItems
that isn’t pointing to a function (like create
, show
, etc.), you’ll get this error. I don’t know what TS is emitting here for private
variables, but I assume it’s not doing too much by default, so if those are visible (even as _Component
), the validator will fail. (In the sample from the repo, these are using the new private field syntax in JS, which means that the validator can’t see them at all.)
But – doing it with a function is a perfectly fine way too. Given that React has been moving away from classes, it’s probably a good idea to update the sample so that it uses a similar tactic.
To your questions:
- Not yet. All panels will be displayed at load, and all panels will show at (0,0). It’s a pain, I know, and we are working on adding some things to the manifest that would allow you to indicate your preferred initial configuration (this would also apply to the first use by a user installing from the marketplace.) I do not have a firm timeline for when this will make it in, but it’s something of which we’re very aware.
-
hide
,destroy
were intended to be implemented for MAX 2020, but didn’t get there in time. We’re building those out now. Same forplugin#create
andplugin#destroy
. - Don’t assume/expect that you’ll be notified when your plugin is going away – a user can always “Force Quit” the app or just turn the machine’s power off. So saving settings when they are changed (vs waiting until the panel is destroyed) is the way to go. Sounds like you’re already doing the right thing here!
For the user, the # of panels is the biggest issue at the moment. Geographic Imager has a similar problem where it opens 6 panels on first launch after installing it. The user must then unstack them and set up their workspace. That’s where the initial layout that we want to add to the manifest will help – you can specify which of your panels should be initially visible, and if they should be grouped together, and roughly where they should appear (though we’re not planning to support x,y coordinates. Hard to do with all the various screen setups out there.)
One thing I want to hone in on as well — don’t assume that your plugin will always be active in the current Ps context. It is currently, but may not be in the future should Ps decide to be more strict about memory management and the like. For example, once you have the other lifecycle methods that you can use, you may want to reload your settings on plugin#create
. But you can’t do that just yet – just letting you know for the future.