search

jorgebucaran / superfine

Absolutely minimal view layer for building web interfaces
https://git.io/super
MIT License
1.57k stars 78 forks source link

change patch semantics to append mode #174

Closed osdevisnot closed 4 years ago

osdevisnot commented 5 years ago

This is one possible fixe for #172. We change patch semantics to use append to container like in v6

I assume this will break SSR as recycling might need more work. But without tests added to V7 branch, I can't tell this certainly.

I will try to create another PR which will play with replace container mode.

jorgebucaran commented 5 years ago

@osdevisnot Is this outdated? Just checking because of https://github.com/jorgebucaran/superfine/issues/172#issuecomment-530859774.

osdevisnot commented 5 years ago

I was attempting to present alternative solutions. This one in particular is untested for SSR, so I won't consider merging this unless we know SSR works correctly.

osdevisnot commented 5 years ago

@jorgebucaran I would like to see if this approach would work for SSR scenarios. Do you have WIP tests that I can use. If not, I can try importing relevant tests from V6.

Also, for root node semantics, did we have strong reason to replace vs append? The reason I ask is because it's a bit untraditional to follow the later.

jorgebucaran commented 5 years ago

@osdevisnot I don't want to append. I want to replace (recycling if possible).

osdevisnot commented 5 years ago

Got it, I'm guessing it brings obvious advantages which I am definitely missing here. If it's not an hassle, do you mind enlightening me on 'why' part of replace vs append?

jorgebucaran commented 5 years ago

I want to take over an HTML node and replace it with my own view. My view can be anything I want or it can be the same as existing HTML content in the document to take advantage of Superfine's recycling.

I also want to find a solution to #172, but not by changing Superfine's default patch behavior. What other options do we have?