justinmc
commented
7 years ago Where we're at now:
- When an app is fetched, an email widget is hacked into its
widgetsarray at position 0. - When submitted, the email widget calls /session/start/
and receives a session id, then immediately calls /session/outputs/ to save the email data. - Output data for this widget is stored into the
pipeDatasmap underrun. This is currently a flat map using a complicated string key. It should probably be a nested object, as long as it's not horrible to use the widgetId and then the pipeId to look it up. - It then adds the sessionId/runId to the URL
- Changing the URL causes it to re-fetch the app and the session from the server (this might be a bug or might be desired...). (code)
- At the LOAD step, we're still using
executeApp1Step0. Instead it should use a generic execution route and the docker command/image should be specified in the widget. (code) - Things break at this point.
What needs to change for MVP:
pipeDatasneeds a permanent solution.- The frontend needs to get rid of "exectuteApp0Step0" etc. calls and use something generic.
- LOAD needs to be finished migrating over to use
pipeDatas. - SELECTION needs to be updated to use
pipeDatas. - RUN needs to be written. UI, integration with new api endpoint(s) to submit workflow and check status, integration with
pipeDatas. - The overall app needs to be refactored to get rid of the thank you page, error page, and that whole flow. Some code can probably be reused in the RUN widget.
- The RESULTS widget needs to be modified to use
pipeDatasand be a normal widget, not a special app state. - Probably lots of additional cleanup, testing that all apps work, and testing that apps are truly generic and can be composed using the json spec as is.
This PR will probably sit for awhile while this project slows down, but I plan to start back up right here when I can!
When finished, this will use the session API to save state at every widget. It will also move the email entry to its own widget at the start to enable this.
It also requires a refactor of
pipeData. I've hacked around this by keeping it as a flat Map, but keying it on a json string: { name, sourceWidgetId }. I may change this to match the server data, where it's nested by widgetId.Next step here is to get RUN to work. This probably means getting rid of the Thank You page, or moving that page into the View pane. This may be a good use case to start using the web socket.