- Issue created by @cosmicdreams
- πΊπΈUnited States cosmicdreams Minneapolis/St. Paul
Do we need this per user? Maybe we can just have this be a global setting.
- Assigned to cosmicdreams
- @cosmicdreams opened merge request.
- πΊπΈUnited States cosmicdreams Minneapolis/St. Paul
Next Steps
* Default the state of the checkbox to checked.
* Add an onload behavior to the checkbox to wait until the page loads then,
1. Open the dialog if checked (be default)
2. Load the dialog in an unopened state if not checked? - πΊπΈUnited States cosmicdreams Minneapolis/St. Paul
With β¨ "Auto" preview option that updates on field blur Fixed merged in we can now focus on improving this issue. The checkbox of π Consider converting toggle preview button into a checkbox Closed: outdated can be reduced in complexity to just opening / closing the dialog. I'll work to reduce that complexity here.
- π¨π¦Canada mandclu
I understand the appetite to not rely on clicking a hidden button to make the functionality rely on simulating clicks on a hidden button, but it feels to me like we're duplicating a lot of code from the existing node preview methods to make it work. Even then, when Preview Pane opens automatically it's giving me a fatal error in the Preview pane when starting a new node:
Would it make sense to have the work in this issue really focus on implementing the checkbox and related JS changes (localStorage etc) that seem to be working well, and move the work of reducing dependence on the hidden preview button to a separate issue? Worth noting that the auto preview still relies on simulated clicks on the preview button, so reducing this dependence in a separate issue could also allow us to deal with it more holistically, which is outside the scope of this issue, at least as currently defined.
- Status changed to Needs review
over 1 year ago 8:55am 5 April 2023 - π¨π¦Canada mandclu
Here's a patch that takes the more modest approach proposed in the previous comment.
- πΊπΈUnited States cosmicdreams Minneapolis/St. Paul
@mandclu indeed that is where I landed yesterday. π Directly render preview, don't simulate click Postponed is the issue where I'm continuing to pursue the challenge of getting all of this to work without the "easy mode" off-canvas enabled button. When I have gotten pieces of it to work, other pieces haven't.
Right now it seems like the main difference is that using the button allows the data to flow through dispatched events from Symfony's event dispatcher, which sends the processing to MainContentViewSubscriber, which eventually delegates to the OffCanvasRenderer. By the time the request processing gets to the OffCanvasRenderer, the data has been decorated with all the needed attachments and compiled data.
The part that I need to duplicate is the data prep work that is happening there. It appears that declaring the '_wrapper_format' might be the key missing signal that my sub_request approach is missing. And I'm exploring that (you know, for fun).
If successful I think the win here would be that we wouldn't need to rely on being forced to use buttons. There isn't anything in the documentation that specifically declares that if you want an off canvas dialog, you MUST use a button to launch it. So i'll continue down this road to see if anything comes from it.
- πΊπΈUnited States cosmicdreams Minneapolis/St. Paul
Regarding #11:
Ah I see, there's no need to create an ajax callback because we're leveraging the existing CloseDialogCommand that is associated with the close button of the dialog. Yes, I like that approach if we can't be rid of the button.
Can you create this as an MR?
- π¨π¦Canada mandclu
Happy to make an MR, but it doesn't seem like I have that option currently. If you could create an additional MR, I will push changes to it
- π¨π¦Canada mandclu
Just tested with the latest code. Still getting a fatal error on initial load.
- Status changed to Closed: duplicate
over 1 year ago 3:10am 9 April 2023 - πΊπΈUnited States cosmicdreams Minneapolis/St. Paul
With β¨ Checkbox with localStorage, trigger existing elements Fixed merged in, and this issue focusing on the same work. We won't have to pursue this one anymore. In π Directly render preview, don't simulate click Postponed I am continuing my pursuit of a solution that doesn't involve clicking a button to launch the dialog. That pursuit might be foolish because there may always be need of a triggering element to launch the dialog, and the site currently doesn't not provide a means for the off-canvas dialog to be open by default (without triggering it).
But I put a lot of work into that and I don't want to lose it.
So... closing this one but it'll stay around for historical purposes.