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
Since implementing #446 there is no longer a way to work with the Tasks module (or any other field module) in a live development environment that watches for changes in the field-module-tasks directory and hot reloads the app in the browser.
Way back when we had separate farmOS-client and farmOS-native repositories (see #92), I had installed the native repo as a devDependency in the client repo, and a similar thing could be done here, where field-module-tasks could install field-kit as a devDependency and then load Tasks during compilation. I don't really like that, since it's a step backwards towards the whole notion of a "buildtime" module, which doesn't really make sense and constrains the API for field modules going forward.
Ultimately, I'd like to mock the farmOS endpoint, /api/field_module/field_module, and serve up some JSON that just points somewhere else on the file system, rather getting proxied to the farmOS server on localhost. That may take some doing, however, especially if it depends on having source maps set up properly, which should be done regardless, but in the interest of time I might have to strike some kind of compromise between those two options.
The text was updated successfully, but these errors were encountered:
Ultimately, I'd like to mock the farmOS endpoint, /api/field_module/field_module, and serve up some JSON that just points somewhere else on the file system, rather getting proxied to the farmOS server on localhost. That may take some doing, however, especially if it depends on having source maps set up properly, which should be done regardless, but in the interest of time I might have to strike some kind of compromise between those two options.
I just went for it and set up the mock server, since I needed it to serve the entry point that calls window.mountFieldModule() anyways. It certainly wasn't the hardest part of the setup, but in any event, this is all resolved now. See #496 for the full history.
Main issues:
- Package Tasks as a separate Field Module #446
- Set up a new development environment for working with Field Mo... #491
- Reduce loading time on startup #495
Since implementing #446 there is no longer a way to work with the Tasks module (or any other field module) in a live development environment that watches for changes in the
field-module-tasks
directory and hot reloads the app in the browser.Way back when we had separate
farmOS-client
andfarmOS-native
repositories (see #92), I had installed the native repo as adevDependency
in the client repo, and a similar thing could be done here, wherefield-module-tasks
could installfield-kit
as adevDependency
and then load Tasks during compilation. I don't really like that, since it's a step backwards towards the whole notion of a "buildtime" module, which doesn't really make sense and constrains the API for field modules going forward.Ultimately, I'd like to mock the farmOS endpoint,
/api/field_module/field_module
, and serve up some JSON that just points somewhere else on the file system, rather getting proxied to the farmOS server on localhost. That may take some doing, however, especially if it depends on having source maps set up properly, which should be done regardless, but in the interest of time I might have to strike some kind of compromise between those two options.The text was updated successfully, but these errors were encountered: