[look997]

#react #programowanie #javascript

Czy istnieje w React odpowiednik... element.append/before/after?

Chodzi o zmianę miejsca elementu, ale nie poprzez klonowanie ani tworzenie na nowo identycznego elementu, a faktyczne przeniesienie elementu.

Tak jak tutaj w VaniliaJS:
https://vw36m.csb.app/
Jak kliknąć "More", to element "Widget" przenosi się z article bo body i z powrotem - ten sam element, bez żadnego szwenku - z użyciem element.append.

Jeśli takie coś istnieje w react to jak się nazywa?

(ja mam pomysł na API, jak takie coś można by robić w deklaratywnym stylu, w JSX, ale może jednak już istnieje?)

[look997]

@LazyInitializationException: Nie zrozumiałeś.
Ten sam element ma się przenosić w różne miejsca w DOM, a nie tworzyć i znikać inny ale identyczny.

[look997]

@LazyInitializationException: Np. że cała zawartość się kasuje.
Wtedy by trzeba zawartość zapisywać na zewnątrz i przypisywać... Mnóstwo niepotrzebnej pracy.

Ale jak nie wiesz czy takie rozwiązanie istnieje to trudno. No chyba że wiesz, że nie istnieje?

[W.....a]

@look997: zamiast przenosić to zrób drugi element z tymi samymi danymi i ukrywaj na clicku imho.

+ możesz takie coś animować cssem
+ lecisz z useState lub reduxa mapę state to props
+ powinno być wydajniejsze

- masz więcej DOMu

[Chanandler]

@look997: Portal? https://pl.reactjs.org/docs/portals.html

[look997]

@LazyInitializationException: Nie wydaje mi się, żeby React wiedział, że te dwa elementy zamknięte w if-ie, są ze sobą powiązane. Musiałoby analizować podobieństwo zawartych w if-ach elementów. A z założenia one mają i tak się nieco różnić. To jest raczej niewykonalne, żeby React wiedział o ich powiązaniach sam z siebie, bez wskazania tych powiazań.

[look997]

@WydajnaJednostkaIndywidualna: W sumie jeśli chodzi o sam stan, to raczej jest racja, że można się o to useState oprzeć.

Szukam sytuacji, gdzie to nie wystarczy...
Może jakby ten przykład który podałem działał tak: zaczynam coś wpisywać do inputa, i wtedy widget się przenosi?
Żeby karetka wpisywania zachowała swoje miejsce, żeby nie musieć tego przenosić ręcznie?

Muszę sprawdzić w tym swoim przykładzie, czy jak używam element.append, to mi stan zaznaczenia w

[look997]

@WydajnaJednostkaIndywidualna: Ha! Jednak przy element.append też nie do końca zachowuje ciągłość.
Focus z input-a znika - to da się łatwo naprawić.
Ale nie znika pozycja kursora w inpucie - to na plus.
Za to np. Ctrl+z działa tylko do miejsca przejścia - czyli jak zacznę pisać, to po pierwszej literze widget się przenosi(takie działanie ustawiłem), a potem Ctrl+z nie kasuje tej pierwszej wpisanej litery. Cofania działa tylko do miejsca, w którym

[kozunio12]

@look997: a to nie jest tak, że ten element został przerenderowany w vdom i dlatego znika historia?

[look997]

@kozunio12: Patrz na przykład - https://vw36m.csb.app/
Ja to testuję na Vanilia JS i w nim to działa w ten sposób.

z vdom to na pewno by znikała, bez wątpienia - dlatego zastanawiam się nad rozwiązaniem, zachowującym ciągłość.

[look997]

@Chanandler: Nie, Portals to nie to.
U mnie element ma być w dwóch miejscach - raz w jednym, raz w drugim.
Portals sprawia, że mimo że jest w jednym, to jest traktowany jakby był zagnieżdżony w innym.
Po prostu rozwiązuje to inny problem.

[rimyi]

@look997: Próbujesz rozwiązać problem, który w realnym świecie nie istnieje. Twój przykład działa, bo za każdym razem przekazujesz stany obu komponentów, więc zawsze będziesz mieć dostęp do ich zawartości.
Zobacz sobie dokumentacje replaceWith i odnośnik do specyfikacji. Zamieniając te elementy, usuwasz je z drzewa DOMu i dodajesz je z powrotem z dodaną referencją
https://dom.spec.whatwg.org/#concept-node-replace

W reakcie załatwiasz to stanem/contextem/reduxem, czymkolwiek.

[look997]

@rimyi: Ale historia wpisywania w inpucie nie działa.
próbuję teraz z event-em beforeinput.
Oczywiście replaceWith tego nie rozwiązuje, zdążyłem się zorientować.

[rimyi]

@look997: historia wpisywania?

[look997]

@rimyi: Ctrl+z
Ja o tym wyżej już pisałem. :|

[rimyi]

@look997: W twoim przykładzie też nie działa ¯\_(ツ)_/¯ Na keypress przechwyć oba przyciski i zapisz ten stan

[look997]

@rimyi: wolę event input, bo obsługuje wszelkie formy wprowadzania treści.

Teraz nie działa na Firefoksie, bo on nie obsługuje jeszcze beforeinput.

Na Chrome działa.