Zachowaj nawigację lokalizacji w adresie URL

Redaktor filtruje wpisy Contentful do jednego typu treści, wybiera lokalizację źródłową, wyszukuje kampanię i otwiera stronę wymagającą przeglądu.

Po sprawdzeniu tłumaczenia klika wstecz i widzi domyślną listę treści.

Dane nadal tam są. Kontekst pracy zniknął.

Stan nawigacji jest częścią zadania

Ekrany lokalizacji często mają kilka wymiarów:

• projekt
• lokalizacja źródłowa i docelowa
• typ treści
• stan tłumaczenia
• zapytanie wyszukiwania
• kolejność sortowania
• strona

Te wartości określają, nad jaką pracą redaktor aktualnie pracuje. Traktowanie ich jako tymczasowego stanu komponentu sprawia, że workflow staje się kruchy przy nawigacji, odświeżaniu i udostępnianych linkach.

Adres URL jest naturalnym miejscem dla możliwego do odzyskania stanu nawigacji.

Wstecz powinno znaczyć wstecz

Redaktorzy wielokrotnie przechodzą między widokami listy i szczegółów. Sprawdzają wpis, przeglądają zgłoszenie, wracają do kolejki i otwierają kolejny element.

Gdy filtry i paginacja znajdują się w query string, historia przeglądarki zachowuje tę pętlę. Użytkownik wraca do tego samego wycinka pracy zamiast odtwarzać go po każdym widoku szczegółów.

To nie jest tylko kwestia wygody. Zmniejsza to ryzyko, że recenzent przypadkowo przełączy lokalizacje lub partie po utracie kontekstu.

Widoki, które można udostępniać, poprawiają koordynację

Adres URL ze stabilnymi filtrami można udostępnić współpracownikowi:

?locale=fr&content_type=landingPage&state=failed

Odbiorca otwiera ten sam widok operacyjny zamiast podążać za pisemnymi instrukcjami, jak go odtworzyć.

Wsparcie i debugowanie również stają się szybsze. Link może zachować odpowiedni stan wyszukiwania i statusu, podczas gdy identyfikatory techniczne pozostają dostępne na stronie.

Wrażliwych danych nie należy umieszczać w adresie URL, ale zwykłe filtry treści to dokładnie ten rodzaj stanu, z którym parametry zapytania radzą sobie dobrze.

Ustanów kanoniczną postać zapytania

Trwałe adresy URL wymagają dyscypliny. Wiele kolejności parametrów, puste wartości, zduplikowane wartości domyślne i nieaktualne numery stron mogą tworzyć mylącą historię.

Dobra implementacja powinna:

1. walidować wartości zapytania po stronie serwera
2. pomijać wartości domyślne tam, gdzie to możliwe
3. resetować paginację przy zmianie filtra
4. zachowywać niezwiązane, ale poprawne filtry
5. zastępować historię przy szybkich zmianach wyszukiwania i dodawać wpis do historii przy celowej nawigacji

Rezultatem jest adres URL, który reprezentuje widok, nie stając się przy tym dopisywanym bez końca zapisem każdej interakcji z interfejsem.

Utrzymuj wspólne kontrolki w synchronizacji

Selektory lokalizacji pojawiają się na listach treści, w szczegółach wpisu, przeglądzie tłumaczenia i ekranach partii. Każda kontrolka powinna odczytywać i zapisywać dane do tego samego modelu nawigacji.

Jeśli jeden selektor zmienia stan lokalny, a inny aktualizuje trasę, użytkownicy widzą niespójne etykiety, a zgłoszenia mogą zostać utworzone z niewłaściwą lokalizacją.

Stan adresu URL walidowany po stronie serwera zapewnia jedno, jasne źródło prawdy o bieżącym kontekście przeglądania.

Najważniejszy wniosek

Filtry nie są jednorazowymi ustawieniami interfejsu, jeśli definiują pracę znajdującą się przed redaktorem.

Utrwal lokalizację, wyszukiwanie, typ treści, status i paginację w kanonicznym adresie URL. Nawigacja wstecz staje się niezawodna, widoki można udostępniać, a praca nad tłumaczeniem przetrwa zwykłe przechodzenie między listami i szczegółami.