search

keystonejs / keystone-classic

Node.js CMS and web app framework
http://v4.keystonejs.com
MIT License
14.64k stars 2.21k forks source link

Lists registered after keystone.start may produce 'Invalid field type' in the admin UI #3035

Open geloescht opened 8 years ago

geloescht commented 8 years ago

Expected behavior

I can register lists at any time in the application lifecycle and all its fields will show up correctly in the admin UI.

Actual behavior

The admin UI shows Invalid field type XYZ at path path for fields that have a type, that has not been seen in any list registered before invocation of keystone.start.

Steps to reproduce the behavior

That's it.

How to fix this

Dynamically rebuild bundles whenever keystone.fieldTypes changes.

JedWatson commented 8 years ago

Oh I did not have that use-case in mind when I built our Browserify build process... Is there a particular reason you can't know all the lists before Keystone starts? Because this is probably going to get worse over time if we start building extension points into the Admin UI as well (e.g. a plugin hook system)

If we want to support this, we'll need to expose some API to rebuild the whole Admin UI after changes to lists are made. Not impossible, I just hadn't thought of it...

geloescht commented 8 years ago

We have our own kind of plugin system, where plugins can be loaded on demand. Usually plugins are started when the server starts, but this process is async. Waiting for all plugins to be loaded before calling keystone.start would add a whole new layer of complexity. Rebuild could happen automatically in the same way that watchify works. Whenever a new field type is detected in a list, wait a little, then rebuild. I tried to implement this but failed to replace the stream by a new version in browserify (see discussion on slack)