Czemu ludzie dodają redundantne nawiasy do komponentów?

Praktycznie w każdym projekcie który odpala widzę taki zapis

return (
  <p>
    <JakiśKomponent/>
  <p/>
);

Ale nie rozumiem zupełnie czemu to niby ma służyć?

Czemu nie taki zapis?

return <p>
  <JakiśKomponent/>
<p/>;

Wiadomo że nie można dać nowej linii po return, bo JS uzna że to jest nowy statement, ale nadal nie rozumiem czemu ktoś chciałby to zrobić? Ten nawias dodaje dodatkowy indent, i swoją drogą moim zdaniem ciężej się przez to czyta kod.

Ale może coś mi umyka?

Pierwszy zapis jest dla mnie bardziej czytelny - tak, jak masz np. funkcję czy jakiś blok (chociażby przy for) to obejmujesz go nawiasami i od razu widać, gdzie dany blok się kończy. Tak samo tutaj - masz return, po nim objęte nawiasami to, co ma zostać zwrócone.

To są takie nawyki/zwyczaje, które zwiększają czytelność - masz parę znaków więcej, ale w niczym one nie przeszkadzają, za to łatwiej się czyta kod.

Tak samo jak np. wpis kolegi @Manna5 na blogu - Oto wyjaśnienie ukrytego błę... i mój komentarz do niego - Dlatego dobrze mieć nawyk ZAWSZE dawania klamerek czy innych elementów tworzących blok - nawet, jeśli jest w nim tylko jedna linia kodu.. Podobnie, jak np. w niektórych językach można wywołać funkcję bez nawiasów (jeśli niczego do niej nie przekazujemy), ale ja zawsze i tak staram się zrobić funkcja() zamiast funkcja. Przy takim wywołaniu wprost to jeszcze nie razi, ale jak masz zmienna = funkcja to jeśli nie dasz nawiasów, to możesz na pierwszy rzut oka nie załapać, czy ta funkcja to jest nazwa funkcji, która coś ma zwrócić, czy nazwa zmiennej, wartość której chcesz podstawić do zmienna.

cerrato napisał(a):

Pierwszy zapis jest dla mnie bardziej czytelny - tak, jak masz np. funkcję czy jakiś blok (chociażby przy for) to obejmujesz go nawiasami i od razu widać, gdzie dany blok się kończy. Tak samo tutaj - masz return, po nim objęte nawiasami to, co ma zostać zwrócone.

To są takie nawyki/zwyczaje, które zwiększają czytelność - masz parę znaków więcej, ale w niczym one nie przeszkadzają, za to łatwiej się czyta kod.

A też piszesz

return (
  true
);

zamiast

return true;

?

Nie kupuję tego wyjaśnienia, bo z zapisem bez nawiasów też widać gdzie się zaczyna i kończy blok - ten render w JSX zawsze jest ostatnią linijką (chyba że mamy kilka returnów), więc nie ma potrzeby dodawać tego nawiasu.

Tak samo jak np. wpis kolegi @Manna5 na blogu - Oto wyjaśnienie ukrytego błę... i mój komentarz do niego - Dlatego dobrze mieć nawyk ZAWSZE dawania klamerek czy innych elementów tworzących blok - nawet, jeśli jest w nim tylko jedna linia kodu.. Podobnie, jak np. w niektórych językach można wywołać funkcję bez nawiasów (jeśli niczego do niej nie przekazujemy), ale ja zawsze i tak staram się zrobić funkcja() zamiast funkcja. Przy takim wywołaniu wprost to jeszcze nie razi, ale jak masz zmienna = funkcja to jeśli nie dasz nawiasów, to możesz na pierwszy rzut oka nie załapać, czy ta funkcja to jest nazwa funkcji, która coś ma zwrócić, czy nazwa zmiennej, wartość której chcesz podstawić do zmienna.

Zgadzam się z klamerkami {} dla for, if, while, i funkcji. Ale tutaj nie ma klamerek - są nawiasy.

Jedyny mało techniczny powód jaki ku temu widzę to taki że wtedy tag otwierający i zamykający będzie na tej samej linii, tylko że to nie jest do końca istotne, bo jeśli tag ma dzieci to jego dzieci tak czy tak będą aligned, a jeśli jest samozamykająćy się to wtedy to nie ma znaczenia i tak.

Poza tym, w IntelliJ jest opcja żeby alginować tagi nawet bez głupich nawiasów:

Więc jesli ktoś chce mieć tagi aligned, to czemu miałby z niej nie skorzystać zamiast dodawać niepotrzebne elementy do kodu.

są nawiasy. tagi html to nie nawiasy

EDIT: nvm, zle Cie zrozumialem.

Żeby tag otwierający i zamykający były na tym samym poziomie wcięcia. Tak jest ładniej i wg. mnie czytelniej.

Wyprzedziłeś mniej. Wystarczy spojrzeć na podany przez autora przykład żeby wiedzieć co jest lepiej sformatowane patrząc wyłącznie z perspektywy w tym wypadku elementu <p>xyz</p>.

Stańmy z drugiej strony.

Po co jakieś

return <p>
  <JakiśKomponent/>
</p>;

skoro można

return <p><JakiśKomponent/></p>;

Jeszcze krócej i ja często faktycznie tak robię - o ile sam dodaję nawiasy, żeby wyrównać start i koniec bloku to nie rozumiem chęci robienia nowej linii dla każdego samotnego komponentu w środku.

Możemy też iść w trolling i pytać po co w ogóle nowe linie, skoro można pisać w jednej - i choć odpowiedź jest dokładnie ta sama - dla czytelności - to jednak to już nie mój poziom dyskusji ;) A można jeszcze niżej...

No sorry, ale przykład jest mocno z czapy. W sensie - jest różnica między jednym słowem, które masz zwrócić a jakąś kilkulinijkową konstrukcją - jak podany w przykładzie <p> blalblalbla..... Chociaż ten przykład da się też zapisać tak, jak sugerował (troszkę szyderczo, ale mniejsza z tym) @dzek69 w postaci jednej linijki.

Zgadzam się z klamerkami {} dla for, if, while, i funkcji. Ale tutaj nie ma klamerek - są nawiasy.

No ale co za różnica czy to nawias czy klamerka (która tak w sumie też jest nawiasem i nazywa się nawias klamrowy) albo jakieś inne oznaczeni bloku - np. begin ... end? Chodzi o zasadę - takie jawne zaznaczenie początku i końca bloku jest dla mnie wyraźniejsze/czytelniejsze (ktoś inny może uważać inaczej).

A co najważniejsze - zadałeś pytanie, ja odpowiedziałem i wyjaśniłem. Ty się nie zgadzasz. Myślę, że nie ma sensu ciągnąc tego na kolejne 34 posty, bo i tak żaden z nas nie przekona drugiego. To jak rozmowa o wyższości BMW nad Mercedesem :P

Więc jesli ktoś chce mieć tagi aligned, to czemu miałby z niej nie skorzystać zamiast dodawać niepotrzebne elementy do kodu.

No właśnie, jak ktoś chce i woli to niech pisze tak, a jak preferuje inaczej to niech pisze po swojemu. Naprawdę - nie ma sensu prowadzić o to wojny.
Peace Bro :)

Też nie rozumiem sensu tych nawiasów. Tj. rozumiem, jeśli są wytyczne w projekcie i trzeba się stosować, okej, nie mam problemu z dostosowaniem się pod kogoś, jeśli zaistnieje taka potrzeba. Tym niemniej jak mam coś samemu pisać, to wybieram opcję bez nawiasów. Ale może mi się zmieni, jeśli zobaczę, że to rzeczywiście ma sens, na razie to dla mnie zaciemnianie kodu.

Natomiast jeśli mam już coś dodawać (chociaż też nie zawsze dodaję), to wolę dodać klamerki np. niektórzy otaczają nawiasami coś z .map:

todos.map(todo => (
  <div key={todo.id}>
  </div>)
));

ponieważ wystarczy jakieś refaktor i z takiego mapowania robi się coś takiego:

todos.map(todo => {
  const someComputation = .....
  return <div key={todo.id}> 
     ......
  </div>;
});

więc czemu nie dodać od razu klamerki? Okej, nawias też można jak ktoś chce, ale nawias spełnia rolę bardziej estetyczną jak wspomnieliście (żeby było "czytelniej"), a klamerki faktycznie ułatwiają potem czynienie zmian. Podobnie jak przy ifach warto robić klamerki, nawet jeśli to jedno wyrażenie póki co.

A to nie dla tego, że przez hoisting i złe sformatowanie kod się może zepsuć? Takie potencjalne miesjca można wyłapać na oko, IDE może pomóc, albo można po prostu dodać nawiasy?

raczej ASI (automatic semicolon insertion), tylko że jeśli formatowanie się zepsuje, to wersja z nawiasami też się zepsuje tj. mamy kod dobry:

function jsx() {
	return "JSX";
}
function foo() {
	return (
		jsx()
	)
}

console.log(foo());

loguje "JSX",
ale rozwalmy formatowanie i nawiasy nie pomogą:

function jsx() {
	return "JSX";
}
function foo() {
	return 
    (
		jsx()
	)
}

console.log(foo());

i mamy undefined, bo wtedy komputer myśli, że tam jest return;

Dużo osób używa jakichś Prettierów i nie jestem pewny na 100%, ale być może one robią coś takiego na domyślnym configu.

Tak jak pisze @adamo51.

Możliwe, że to automatyczny styler tak modyfikuje kod.

cerrato napisał(a):

Pierwszy zapis jest dla mnie bardziej czytelny - tak, jak masz np. funkcję czy jakiś blok (chociażby przy for) to obejmujesz go nawiasami i od razu widać, gdzie dany blok się kończy.

No to masz szczęście, że nie musisz czytać kodu w Pythonie. A to podobno jeden z bardziej przystępnych języków dla początkujących.