null czy pominięcie pola
Podsumowanie: `null` mówi, że pole istnieje bez wartości; pominięcie mówi, że pole nie istnieje. Treści PATCH, scalanie konfiguracji i wstępne wypełnianie formularzy to miejsca, w których różnica boli.
Najważniejsze: wysyłaj null, gdy konsument musi odróżnić „wyczyszczone” od „nietknięte” — w treści PATCH pominięcie zostawia pole w spokoju, a jawne null czyści je — i utrzymuj jedną konwencję per pole, aby odpowiedzi i scalanie konfiguracji pozostały stabilne.
Różnica
{ "nickname": null }
Obecne, puste. Konsument wie, że pole zostało jawnie wyczyszczone.
{ }
Nieobecne. Konsument nie potrafi odróżnić „nigdy nie ustawione” od „nieobsługiwane”.
W JavaScript rozróżnienie jest konkretne:
'nickname' in obj // false — absent
obj.nickname === null // true — present and null
obj.nickname === undefined // true — both cases
Gdzie to ma znaczenie
Treści PATCH. {"nickname": null} czyści pseudonim. {} nic nie zmienia. Jeśli handler traktuje „null” i „brakujące” tak samo, użytkownicy nigdy nie potrafią wyczyścić pola — mogą tylko ustawić pusty łańcuch, co jest czym innym.
Implementuj po obecności klucza, a nie wartości:
if (Object.hasOwn(patch, 'nickname')) {
target.nickname = patch.nickname; // null allowed
}
Scalanie konfiguracji. Pominięcie dziedziczy domyślną; null wyłącza jawnie. Dokładnie tak zachowują się wartości Helm i Kubernetes.
Wstępne wypełnianie formularza. null renderuje się jako puste i brakujące pole też, ale wysyłanie się różni: miało wartość, teraz wyczyszczone → wyślij null; nigdy nie wypełniane → pomiń. Bez rozróżnienia czyszczenie wygląda identycznie jak brak dotknięcia.
Konwencje
| Sytuacja | Konwencja |
|---|---|
| Treści odpowiedzi | Zachowaj null; stabilny kształt, prostsze typy |
| Żądania PATCH | null czyści, pominięcie zachowuje |
| PUT (pełne zastąpienie) | Pominięcie znaczy usunięcie — cały dokument jest zastępowany |
| Scalanie konfiguracji | Pominięcie = domyślna, null = wyłączone |
| Baza danych | null dla nieznanych lub nieodpowiednich; '' dla znanych pustych |
Utrzymuj stabilne kształty odpowiedzi. Lista, w której część elementów niesie avatar, a inne nie, wymusza sprawdzenia 'avatar' in item w każdym miejscu wywołania. avatar: null jest łatwiejsze w konsumpcji.
Trzy rzeczy, których nie robić
Nie używaj "" zamiast null. Pusty pseudonim i nieustawiony pseudonim to w większości domen różne stany.
Nie używaj 0 lub -1 jako wartowników. Zero jest legalną liczbą, a wartownik psuje każdą obliczaną średnią.
Nie mieszaj konwencji per punkt końcowy. Dwie konwencje oznaczają dwie ścieżki kodu w każdym kliencie.
FAQ
Co decyduje między null a pominiętym polem?
Zapytaj, czy konsument musi rozróżniać „jawnie wyczyszczone” od „nigdy nie ustawione”. W treści PATCH musi, więc null czyści, a brak zachowuje; w odpowiedziach zachowanie null czyni kształt stabilnym i typy klienta prostszymi.
Jak punkt końcowy PATCH odróżnia czyszczenie od pozostawienia w spokoju?
Sprawdzaj obecność klucza, a nie wartość: Object.hasOwn(patch, 'nickname') mówi, że pole wysłano, i tylko wtedy je przypisz, włącznie z null. Jeśli handler traktuje null i brak tak samo, użytkownicy nigdy nie potrafią wyczyścić pola i mogą tylko cofać się do pustego łańcucha.
Dlaczego treści odpowiedzi powinny zachowywać null?
Stabilny kształt oznacza, że klienci nie potrzebują sprawdzenia 'avatar' in item dla każdego opcjonalnego klucza. Gdy część elementów listy niesie avatar, a inne je pomijają, to sprawdzenie powtarza się w każdym miejscu wywołania i łatwo je źle napisać.