On by default, make off-by-default an opt-in setting

Created on 27 February 2023, almost 2 years ago
Updated 9 April 2023, over 1 year ago

Problem/Motivation

I can image that a user would like to have the preview pane open by default. In Phase 2, we might want to consider remembering the pane open/closed setting.

Should this site-wide vs per user setting?

Proposed resolution

Consider storing this as a user preference.

Remaining tasks

If we want it, store the per user setting.

πŸ“Œ Task
Status

Closed: duplicate

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 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.

  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul
  • Assigned to cosmicdreams
  • πŸ‡ΊπŸ‡ΈUnited States cosmicdreams Minneapolis/St. Paul
  • @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
  • πŸ‡¨πŸ‡¦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
  • πŸ‡ΊπŸ‡Έ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.

Production build 0.71.5 2024