-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: automatically publish newly created flows #4230
Conversation
Removed vultr server and associated DNS entries |
…ss/publish-flow-on-create
@@ -63,7 +65,7 @@ interface InsertFlow { | |||
} | |||
|
|||
// Insert a new flow into the `flows` table | |||
const insertFlow = async ( | |||
const createFlow = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, the editor store function createFlow
should be calling/sharing this API method instead of doing a separate/equivalent frontend mutation ! Have made a note of this for now, but intentionally choosing not to refactor here to keep momentum on templates as a whole - will revisit when adding methods for "createTemplatedFlow"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep - agreed - we want to be narrowing this down to (ideally) a single implementation.
@@ -114,39 +114,7 @@ test.describe("Flow creation, publish and preview", () => { | |||
]); | |||
}); | |||
|
|||
test("Cannot preview an unpublished flow", async ({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
E2E tests always start from an empty database and create a flow from scratch which now includes publishing - meaning they no longer have the concept of ever accessing an "unpublished" flow or needing to test initial publish action separately.
The "publishFlow" action is still called throughout this file to save/publish content changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment in theopensystemslab/planx-core#639 which is worth thinking about / trying out, but no blockers! 👌
@@ -63,7 +65,7 @@ interface InsertFlow { | |||
} | |||
|
|||
// Insert a new flow into the `flows` table | |||
const insertFlow = async ( | |||
const createFlow = async ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep - agreed - we want to be narrowing this down to (ideally) a single implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good to me, tested manually on the pizza a few times and tried to find edge cases around combining creating and publishing flows. Couldn't find anything
…ss/publish-flow-on-create
Realising this will be nice to have in place before templates - as I think we'll want a new
createTemplate
function to follow a similar pattern (offline by default, but is already published)!Applies to both creating a new flow and copying a flow.
E2E tests rely on methods defined in
planx-core
which are updated here theopensystemslab/planx-core#639Testing:
window.api.getState().isFlowPublished