up-hungry on a parent causes up.render() to fail to target · Issue #681 · unpoly/unpoly · GitHub
Skip to content

up-hungry on a parent causes up.render() to fail to target #681

Open

Description

@c33howard

Bug description

I have a parent div with up-hungry. When clicking a button, I call await up-render() with a target of the nested element. The resulting response object has an empty response.fragments array. In unpoly 3.3.0 and earlier, the response.fragments array was populated.

I bisected the problem to this commit:

cc5a31f

Reproduction project

https://glitch.com/edit/#!/honeysuckle-vast-bead

In the repro, you can change the script version. I expect both buttons to be replaced with the string replacement, while an alert demonstrates an empty fragment response. Note that the difference between child-1 and child-2 is up-hungry.

Steps to reproduce the behavior:

  1. Go to reproduction project linked above
  2. Click the child buttons
  3. Success is no alerts

Expected behavior

Button should be replaced with the string replacement-1

Browser version

  • OS: linux
  • Browser brave and firefox
  • Version latest

Additional context

Activity

  1. triskweline commented on Dec 2, 2024

    @triskweline
    Contributor

    Thanks for investigating @c33howard.

    I believe the following happens:

    • When rendering multiple targets, Unpoly has a mechanism to reconcile nested elements.
    • In this we're implicitly targeting #hungry, #child1, which Unpoly reconciles to just #hungry.
    • The response ended up not including #hungry. It did include #child1, but we already removed that from the render pass when consolidating earlier.

    I'm not sure how to improve the behavior. I know we need to keep the reconciliation mechanism.

  2. c33howard commented on Dec 2, 2024

    @c33howard
    Author

    Ah, nested resolution makes sense. When I first read this, I assumed this would also lead to what was send to the server in X-Target, but the server sees X-Target: child1. So, it thinks that just returning #child1 is valid. That seems inconsistent if the client is going to ignore #child1 in the response.

    For more context, I ran across this with a relatively complex autocomplete widget that's sometimes present in a <header> and sometimes in a <footer>. The larger elements are up-hungry, but I don't want to explicitly target them while doing the autocomplete, because that's way more expensive than the autocomplete, and it messes with focus of the text box that triggers the autocomplete.

    Some ideas (from the peanut gallery, I don't understand unpoly's internals).

    • Keep the original explicit targets around and use them from the response
    • Make the reconciliation a list of preferences, ie prefer to render #hungry, but if not found, then render #child1
    • Defer the nested reconciliation until after the server response arrives and include the response in the reconciliation (ie prune options that aren't in the response)
    • Re-run nested reconciliation if there are no matches from the server
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions