Różnica pomiędzy dwoma zapisami obiektu

Question

Czy jest jakakolwiek znacząca różnica pomiędzy poniższymi zapisami obiektu?

let admin = {
    name: 'Admin'
};

let admin = {
    "name": 'Admin'
};

 

Answer 1

W JavaScript nie ma to znaczenia. Ja na przykład preferuję pierwszy sposób ale to rzecz gustu.

Tylko taka uwaga, stosuj jeden rodzaj cydzysłowy albo apostrofy, nie mieszaj. Podgraj sobie jakiś linter np. eslint i poustawiaj odpowiednie regułki to Ci tego przypilnuje sam.

Comments

Również bardziej podoba mi się zapis pierwszy. Drugi rozumiem, że stosuje się do JSON (oczywiście cudzysłów)?

---

jeśli mówimy o JSON to owszem, wtedy "xxx": "xxx", ale moja odpowiedź dotyczyła samych obiektów w JS :)

Zresztą raczej nie będziesz tak wprost tworzył ręcznie JSONów, zazwyczaj po prostu bierze się obiekt JS i puszcza JSON.stringify więc nadal Cię ten zapis nie interesuje.

Answer 2

Pierwszy zapis ogranicza nazwy kluczy do takich, które są zgodne ze składnią js. Przy drugim zapisie praktycznie nie ma takich ograniczeń. Jeśli chodzi o ten konkretny przykład, obiekty są tożsame.

Comments

Podobna różnica występuje przy property accessorach (zapis z nawiasami kwadratowymi vs zapis z kropką).

---

@niezalogowany,

Pierwszy zapis ogranicza nazwy kluczy do takich, które są zgodne ze składnią js. Przy drugim zapisie praktycznie nie ma takich ograniczeń. 

mojego CR byś nie przeszedł taką customową nazwą :) Ja uważam to za błąd i nie ma zmiłuj :)

---

@Tomek Sochacki mocne stwierdzenie. Niemniej taki zapis występuje przy różnego typu konfiguracjach: na przykład axios headers, czy lang codes.

Czasem zajdzie potrzeba zmapowania nieprzyjaznych danych na sztywno: na przykład, gdy kluczem jest tłumaczona fraza

const locale = {
  en: {
    'Hello world': 'Hello world'
  },
  pl: {
    'Hello world': 'Witaj świecie!'
  }
}

---

oki ale to pojedyncze sytuacje. a na marginesie to czemu mialby sluzyc kod z tlumaczeniami? pracuje z apkami wielojęzycznymi i takie rzeczy zalatwiaja pliki tlumaczen, np. po lub xlf itp. Apki to w ogole nie powinno obchodzić :)

---

s przy headers itp to też preferuję wyciaganie np. do stalej i zrobienie klucza wg tej stalej jesli juz jest to potrzebne :)

---

Okej, rozumiem Twoje podejście do zapisu niestandardowych kluczy.

Kod z tłumaczeniami miałby służyć tłumaczeniom :)

---

Oczywiście masz rację, tak nie tłumaczy się aplikacji.

Spójrz na na ten przypadek. Nieprzyjazne dane mogą pochodzić z różnych źródeł, nad którymi nie zawsze mamy kontrolę.