Wykorzystując React.js oraz Angular, stworzono funkcjonalnie równoważne kody źródłowe. Aby móc w metodzie handleSubmit pokazać zawartość kontrolki input w miejscu oznaczonym ???, należy odwołać się do atrybutu o nazwie:
React.js: nazwa1 = React.createRef();
handleSubmit = e => {
console.log(this.???.current.value);
}
...
<form onSubmit={this.handleSubmit}>
<input ref={this.nazwa1} name="nazwa2" id="nazwa3" for="nazwa4" />
Angular: <form #f="ngForm" (ngSubmit) = "handleSubmit(f)">
<input ngModel name="nazwa1" id="nazwa2" class="nazwa3" for="nazwa4" >
...
handleSubmit(f) {
console.log(f.value.???);
}
To właśnie nazwa1 jest właściwym atrybutem, do którego trzeba się odwołać, żeby wyciągnąć wartość inputa zarówno w React, jak i w Angularze. W React, kiedy chcemy pobrać wartość z inputa przez refa, to przekazujemy ref={this.nazwa1}, a potem w handleSubmit robimy this.nazwa1.current.value. To po prostu dokładnie ta sama nazwa, którą przypisałeś do refa, nie ma tu żadnej magii. W Angularze z kolei input posiada ngModel oraz name="nazwa1" – i to name jest kluczowe, bo obiekt f.value generowany przez ngForm zawiera wszystkie pola po kluczach odpowiadających atrybutom name. Dzięki temu możesz potem użyć f.value.nazwa1 i dostajesz wartość inputa. W praktyce zawsze warto pilnować, żeby atrybut name był sensowny i jednoznaczny, bo to na nim opierają się frameworki przy serializacji danych formularza i obsłudze ich stanu. Moim zdaniem to jest jedna z bardziej praktycznych umiejętności przy pracy z dynamicznymi formularzami – jeśli ktoś nie dba o spójność nazw atrybutów name, to łatwo o błędy, które są potem trudne do wykrycia. Warto jeszcze pamiętać, że atrybuty typu id, class czy for mają zupełnie inne zastosowanie – służą do stylowania, powiązań z labelkami, itd. Name natomiast to podstawa logicznej obsługi wartości pól formularza. Często spotykam się z sytuacjami, że ktoś próbuje pobierać dane po id czy class, ale to nie jest zgodne z dobrymi praktykami – dla czytelności kodu i łatwości refaktoryzacji o wiele lepiej korzystać z name. Takie rozwiązania są też zalecane w oficjalnej dokumentacji zarówno React, jak i Angulara.
Wybór atrybutów takich jak nazwa4, nazwa2 czy nazwa3 wynika często z nieporozumienia co do roli poszczególnych atrybutów we współczesnych frameworkach frontendowych. Identyfikator (id), klasa (class) czy nawet for mają swoje konkretne zadania, ale nie służą do powiązania wartości inputów z logiką formularza. Id stosujemy typowo do jednoznacznego oznaczania elementów w DOM-ie, co ułatwia stylowanie lub selektory JavaScript, jednak nie ma bezpośredniego przełożenia na to, jak frameworki typu React czy Angular pobierają wartości pól w formularzach – szczególnie jeśli korzystamy z referencji bądź systemu ngForm. Podobnie atrybut class ma charakter czysto prezentacyjny: używamy go do przypisywania styli CSS, ewentualnie do selektorów w testach automatycznych, ale nie do obsługi zdarzeń związanych z danymi formularza. For natomiast jest przydatny tylko w kontekście etykiet (label), by skojarzyć ją z konkretnym polem po id – nie wpływa na to, jak framework zbiera wartości inputów podczas submitowania formularza. Najczęstszym błędem, który obserwuję, jest zakładanie, że skoro id czy class są unikalne lub opisowe, to można przez nie pobierać wartości pól – to nie jest zgodne ani z dokumentacją Reacta, ani Angulara, ani standardami HTML5. To właśnie atrybut name pełni rolę logicznego identyfikatora wpisu w kontekście formularza: w Angularze ngForm buduje obiekt value na podstawie name każdego inputa, a w React – jeśli korzystasz z refów – również najwygodniej jest konsekwentnie opierać się o te same atrybuty, żeby formularze były czytelne i łatwe do utrzymania. W praktyce, kiedy ktoś wybiera inne atrybuty, ma to zwykle związek z brakiem znajomości architektury pracy z danymi w danym frameworku. Warto więc przeanalizować, jak frameworki mapują dane formularza i co wynika z oficjalnych tutoriali i dokumentacji. W dłuższej perspektywie praca z formularzami staje się wtedy dużo prostsza i mniej podatna na błędy, a kod jest bardziej przewidywalny i skalowalny.