search

easyblockshq / easyblocks

The open-source visual builder framework.
https://easyblocks.io
GNU Affero General Public License v3.0
346 stars 55 forks source link

feat(editor) include query parameters as editor params #60

Open maarten2424 opened 5 months ago

maarten2424 commented 5 months ago

Description

Currently, the following query parameters are only mutable on the URL.

The editor page takes a few important query parameters:

readOnly <boolean> = true - if set to true, no permanent modifications will be done to existing documents or templates. Very good way to play around, debug components, documents, etc. When you open the editor page directly it's by default set to true in order to prevent unexpected modifications.

document <string> - the id of the document you want to open. Leaving it undefined means you're creating a new document.

rootComponent <string> - the id of the root component. Mandatory when creating a new document (document param is not set).

rootTemplate <string> - the id of the template to copy when creating a new document. Can't be specified together with rootComponent.

locale <string> - a locale id. The locale must exist in Config.locales.

This MR enables the parameters to be set as parameters on the editor itself, making them mutable and react when changed. This way changes to any of these parameters won't result in a refresh of the editor, and making it more usable in dynamic hosted environments.

vercel[bot] commented 5 months ago

@maarten2424 is attempting to deploy a commit to the Shopstory Team on Vercel.

A member of the Team first needs to authorize it.

r00dY commented 4 months ago

@maarten2424 So the assumption is that you can re-render the editor based on input params, right? It makes sense, although I'm not sure it will work right now with the changes in the PR. There are some useEffect with [] dep array or memo in the initial render phase of the editor. Unless those are addressed I don't think it's gonna work. How was it tested?

maarten2424 commented 4 months ago

Exactly, changing those will re-render easyblocks. There where some initial issues with the memo and document ID's for the form, but it seems to work properly now. I've tested changing all the properties directly and the edit seems to re-render quickly!

r00dY commented 4 months ago
  1. Shouldn’t we show some loader when Editor is being reloaded?
  2. Shouldn’t we force-save old content when reload happens?
  3. Have you tested the history stack between reloads (should be nulled)?

Loose thought: what if we just unmount the root editor, show loader and mount the editor root component again? It could also work without loader. Wouldn't it meet your criteria? It would be much more bulletproof as there would be no state dependence between old and new instances. And there's quite a lot of state over there...

maarten2424 commented 4 months ago
  1. Shouldn’t we show some loader when Editor is being reloaded?
  2. Shouldn’t we force-save old content when reload happens?
  3. Have you tested the history stack between reloads (should be nulled)?

Loose thought: what if we just unmount the root editor, show loader and mount the editor root component again? It could also work without loader. Wouldn't it meet your criteria? It would be much more bulletproof as there would be no state dependence between old and new instances. And there's quite a lot of state over there...

Good point on the state management. I've been trying to overcome the loading and do instant state change, but I think initialisation time would be minimal. Let me prototype this idea in this PR and come back to you!