Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(ui): persisted workflow collection generators #7559

Conversation

psychedelicious
Copy link
Collaborator

@psychedelicious psychedelicious commented Jan 15, 2025

Summary

Previously (i.e. as implemented in #7545 & #7553), workflow generators existed on a layer above the workflow and were ephemeral. Generators could be run and the result saved to the workflow.

There was no way to have the generator and its settings to be an inherent part of the workflow. When you refresh the page or load a workflow, the generator settings are reset.

For example, a number collection field's value is a list of numbers. When you use a range generator for that field, the generated list of numbers is written to the workflow. When you refresh the page or load the workflow later, all you have is the list of numbers.

This change makes generators a part of the workflow itself. In other words, the a field's generator settings are persisted to the workflow alongside the field, and eligible fields can be thought of as having a generator as their state.

For example, consider a number collection. If the field has a generator enabled, the generator settings are stored in the workflow directly, in that field's state. When we need to access the field's value, if it has a generator, we run the generator. If there is no generator, we get the directly-entered value.

This enables an important use-case, where the workflow editor can set up a good baseline generator and save it to the workflow.

Then the workflow user loads the workflow, and they just see the generator settings, importantly with the default values set by the editor. They never need to see a big list of values.

  • Add generator persistence to number collection field values.
  • Update all logic that references field values to use "resolved" field values if the field is a number collection field. This includes validation logic.
  • Rework the generator UI. Generators are now part of each field, not a separate modal. You can enable the generator, reset its values, commit them and then edit them. Or, disable the generator to manually edit the values.
  • Support locking the linear view mode. If the workflow editor locks the field, the linear view will be slimmed down, showing only the generator fields.
  • Rework how the "reset to default value" functionality works with exposed fields to also work with generators. Unfortunately, this did require some changes to redux state that I cannot easily handle in a redux state migration. As a result, on the first run after updating Invoke, their workflow editor state will be erased.

Related Issues / Discussions

offline discussion

QA Instructions

Try it out.

Merge Plan

This is dependent on #7553 .

Checklist

  • The PR has a short but descriptive title, suitable for a changelog

@github-actions github-actions bot added python PRs that change python files invocations PRs that change invocations frontend PRs that change frontend files labels Jan 15, 2025
@psychedelicious psychedelicious force-pushed the psyche/feat/zipped-batches branch from 3fe8ae4 to 74a4197 Compare January 15, 2025 23:21
Previously, workflow generators existed on a layer above the workflow and were ephemeral. Generators could be run and the result saved to the workflow.

There was no way to have the generator and its settings to be an inherent part of the workflow. When you refresh the page or load a workflow, the generator settings are reset.

For example, a number collection field's value is a list of numbers. When you use a range generator for that field, the generated list of numbers is written to the workflow. When you refresh the page or load the workflow later, all you have is the list of numbers.

This change makes generators a part of the workflow itself. In other words, the a field's generator settings are persisted to the workflow alongside the field, and eligible fields can be thought of as having a generator _as_ their state.

For example, consider a number collection. If the field has a generator enabled, the generator settings are stored in the workflow directly, in that field's state. When we need to access the field's value, if it has a generator, we run the generator. If there is no generator, we get the directly-entered value.

This enables an important use-case, where the workflow editor can set up a good baseline generator and save it to the workflow.

Then the workflow user loads the workflow, and they just see the generator settings, importantly with the default values set by the editor. They never need to see a big list of values.

- Add generator persistence to number collection field values.
- Update all logic that references field values to use "resolved" field values if the field is a number collection field. This includes validation logic.
- Rework the generator UI. Generators are now part of each field, not a separate modal. You can enable the generator, reset its values, commit them and then edit them. Or, disable the generator to manually edit the values.
- Support locking the linear view mode. If the workflow editor locks the field, the linear view will be slimmed down, showing only the generator fields.
- Rework how the "reset to default value" functionality works with exposed fields to also work with generators. **Unfortunately, this did require some changes to redux state that I cannot easily handle in a redux state migration. As a result, on the first run after updating Invoke, their workflow editor state will be erased.**
@psychedelicious psychedelicious force-pushed the psyche/refactor/ui/persisted-generators branch from facfb84 to 6df3e9f Compare January 15, 2025 23:22
@psychedelicious
Copy link
Collaborator Author

Superseded by #7562.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
frontend PRs that change frontend files invocations PRs that change invocations python PRs that change python files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants