Prefer matching fragments within a given { origin }

Bug description

discovered this when my forms were set to target an inner element, but instead the first matching element on the page was selected (this is a page with a list of forms)

<div>
    <div class="auto-submit d-flex"></div>
    <form
      {% if id %}id="{{id}}"{% else %}id="form_{{name}}"{% endif %}
      up-transition="cross-fade"
      up-target=".auto-submit"
      up-method="{{up-method|default:PATCH}}"
      up-autosubmit
      up-delay="{{up-delay|default:1000}}"
      enctype="multipart/form-data"
      up-history="false"
      action="{{action}}">
        {% block component %}{% endblock %}
        <div class="auto-submit d-flex"> </div>
    </form>
</div>

response

<div class="auto-submit d-flex">
    <img src="/assets/Font-Awesome/svgs/solid/check-circle.svg">
    <p>Profile Upadted !</p>
</div>

my workaround/fix

var selector_closest_fixed = false;
(function fix_selector_closest(){
  if(!selector_closest_fixed){
    selector_closest_fixed = true
    up.Selector.prototype.closest = function(element) {
      var parentElement;
      let child_target = element.querySelector(this.unionSelector);
      if (child_target){
        return child_target
      }
      else if (this.matches(element)) {
        return element;
      } else if ((parentElement = element.parentElement)) {
        return this.closest(parentElement);
      }
    };
  }
})();

Can you confirm you're using Unpoly 2?

up.selector.closest() doesn't look at children, AFAIK. You might need to narrow the selector if it's ambiguous to Unpoly. If you don't want to add another id or class attribute, you could use up-id.

I wasn't able to follow the exact issue from your example. If you have an opportunity and could make a reproducible example using Glitch, it might help. There's a Glitch template to start you off, if so.

i'm using unpoly ~2.0.1 (whatever is latest on CDN)
i tried many selectors for solutions, even up-id
i spent a lot of time on this issue, trying to figure out why my form post was changing html in some random place on my page, nowhere near the origin.
the way selector closest works either is not intuitive, incorrect, or maybe the function should be renamed.

closest really sounds like it should try to do just querySelector(selector), because the closest selection will be that. but closest is doing a recursive search of parents, so it's name should probably be something similar to what it's actually doing, like search_parents or something

since unpoly has the up-content att, i think i can do an example without needing a server. i'll post it soon.

https://glitch.com/edit/#!/ember-mousy-canvas

js has my fix, i can't get the up-document/up-content working (maybe another bug)

i added some style to show what unpoly is changing, js has my fix, remove the fix and see the behaviour difference.

I removed your Javascript changes and updated both up-target to this.

up-target="& .auto-submit"

I believe it achieves what you were looking for. Can you confirm? https://glitch.com/edit/#!/radial-attractive-equinox

yes, maybe this should be emphasised in the documentation. i tried to use :origin in my target, but it didn't work, the & is very unfamiliar to me, and i didn't attempt to use it as a selector.

seems that origin should be implied, though.

would be common that the selector you used would break things for people? for me it seems like the intuitive behaviour and & is redundant.

I did try :origin .auto-submit as a selector and it appears to work. The & selector was linked in the v1 up-target docs, but that's not the case for v2. If you think you can make the docs more expressive in this case, please submit a PR. To be honest, & is more familiar to me than :origin, as I have past experience with Sass.

seems that origin should be implied, though.

I haven't ran into any issues here, so I can't really agree. Maybe Henning can provide an opinion here.

I'm going to close this for now since up.fragment.closest documents that it only looks at itself and then it's ancestors, never its children. If Henning deems this a bug we can re-open.

Please feel free to submit a PR for the :origin documentation if you can find a way to improve it.

Both :origin and & are supported, as documented here.

Even without :origin in the selector, Unpoly 2 tries to take a given { origin } into account when matching fragments. Currently that mostly looks for a parent element around the origin.

I haven't had a use case where I needed to auto-match an origin child, but I guess we could support that.

The fix wouldn't go in up.Selector though, but here:

unpoly/lib/assets/javascripts/unpoly/fragment.coffee

Lines 1033 to 1038 in e555c48

    
           finder = new up.FragmentFinder( 
        
             selector: selector 
        
             origin: options.origin 
        
             layer: options.layer 
        
           ) 
        
           return finder.find()

unpoly/lib/assets/javascripts/unpoly/classes/fragment_finder.coffee

Line 11 in e555c48

return @findAroundOrigin() || @findInLayer()

unpoly/spec_app/spec/javascripts/up/fragment_spec.js.coffee

Lines 63 to 87 in e555c48

    
           describe 'matching around the { origin }', -> 
        
             it 'prefers to match an element closest to origin', -> 
        
               root = fixture('.element#root') 
        
               one = e.affix(root, '.element', text: 'old one') 
        
               two = e.affix(root, '.element', text: 'old two') 
        
               childOfTwo = e.affix(two, '.origin') 
        
               three = e.affix(root, '.element', text: 'old three') 
        
               result = up.fragment.get('.element', origin: childOfTwo) 
        
               expect(result).toBe(two) 
        
             it 'prefers to match a descendant selector in the vicinity of the origin', -> 
        
               element1 = fixture('.element') 
        
               element1Child1 = e.affix(element1, '.child',         text: 'old element1Child1') 
        
               element1Child2 = e.affix(element1, '.child.sibling', text: 'old element1Child2') 
        
               element2 = fixture('.element') 
        
               element2Child1 = e.affix(element2, '.child',         text: 'old element2Child1') 
        
               element2Child2 = e.affix(element2, '.child.sibling', text: 'old element2Child2') 
        
               result = up.fragment.get('.element .sibling', origin: element2Child1) 
        
               expect(result).toBe(element2Child2)

Re-opening this issue for a while in case someone wants to tackle that change.

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

Prefer matching fragments within a given { origin } #197

Bug description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	finder = new up.FragmentFinder(
	selector: selector
	origin: options.origin
	layer: options.layer
	)
	return finder.find()

	describe 'matching around the { origin }', ->

	it 'prefers to match an element closest to origin', ->
	root = fixture('.element#root')
	one = e.affix(root, '.element', text: 'old one')
	two = e.affix(root, '.element', text: 'old two')
	childOfTwo = e.affix(two, '.origin')
	three = e.affix(root, '.element', text: 'old three')

	result = up.fragment.get('.element', origin: childOfTwo)

	expect(result).toBe(two)

	it 'prefers to match a descendant selector in the vicinity of the origin', ->
	element1 = fixture('.element')
	element1Child1 = e.affix(element1, '.child', text: 'old element1Child1')
	element1Child2 = e.affix(element1, '.child.sibling', text: 'old element1Child2')

	element2 = fixture('.element')
	element2Child1 = e.affix(element2, '.child', text: 'old element2Child1')
	element2Child2 = e.affix(element2, '.child.sibling', text: 'old element2Child2')

	result = up.fragment.get('.element .sibling', origin: element2Child1)

	expect(result).toBe(element2Child2)

Sunbelt Computer Software

PL/B Language Development and Support

Prefer matching fragments within a given { origin } #197

Description

Bug description

Activity

adam12 commented on Jun 26, 2021

boxxxie commented on Jun 26, 2021

boxxxie commented on Jun 26, 2021

adam12 commented on Jun 26, 2021

boxxxie commented on Jun 26, 2021

adam12 commented on Jun 27, 2021

triskweline commented on Jun 28, 2021

triskweline commented on Jun 28, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions