Skip to main content
Wysyłaj logi z aplikacji React Native do LogBrew. Zacznij od jednego testowego logu, a potem znajdź go w CLI we właściwym projekcie. Ten przewodnik używa Expo. Aplikacja w czystym React Native (bez Expo) ładuje klucz przez własną konfigurację. Zanim zaczniesz, potrzebujesz:
  • Aplikacji React Native, którą możesz uruchomić lokalnie.
  • Projektu LogBrew. Zobacz Projekty.
  • Zalogowanego CLI. Zobacz stronę Praca z CLI.

Zainstaluj SDK

Zainstaluj oba pakiety w katalogu aplikacji. Zachowaj zależności React i React Native, których używa aplikacja:

Utwórz klucz SDK projektu

Daj aplikacji klucz SDK przypisany do projektu i tylko do zapisu. Expo umieszcza każdą wartość EXPO_PUBLIC_* w pakiecie aplikacji. Nigdy nie umieszczaj w tej zmiennej poświadczenia konta ani serwera. CLI v0.1.32 lub nowszy tworzy klucz dla istniejącego projektu. Nie tworzy nowego projektu. Znajdź ID projektu:
Utwórz klucz. Użyj nowej ścieżki pliku w katalogu dostępnym tylko dla właściciela:
Kontynuuj dopiero wtedy, gdy polecenie się powiedzie. Jeśli wynik jest niejasny, uruchom to samo polecenie ponownie z tymi samymi argumentami. Nie używaj --abandon-retry. Nie dodawaj pliku klucza do systemu kontroli wersji. Nie używaj poświadczenia konta, które autoryzowało CLI. Przy lokalnej pracy z Expo umieść klucz w ignorowanym pliku .env.local w katalogu głównym aplikacji:
Zachowaj bezpośrednie odwołanie process.env.EXPO_PUBLIC_LOGBREW_CLIENT_KEY w module konfiguracji poniżej. Po zmianie wartości w pełni przeładuj aplikację. Konfigurację w czasie builda opisuje strona Zmienne środowiskowe w Expo. Aplikacja w czystym React Native ładuje natomiast klucz przez własną konfigurację.

Utwórz klienta

Umieść tę konfigurację w jednym module, który aplikacja ładuje przy starcie. Nie twórz klienta przy każdym renderowaniu. Umieść usługę, środowisko i wydanie w context:
Transport fetch włącza automatyczne dostarczanie z kolejką i ograniczoną liczbą ponowień. Nie dodawaj drugiego timera do opróżniania kolejki (flush). Listener AppState zleca ostatnie opróżnienie kolejki, gdy aplikacja staje się nieaktywna lub przechodzi w tło. Wywołaj stopAppStateListener(), gdy aplikacja się zamyka. Przy natywnej kolejce z klucza może korzystać tylko jeden aktywny klient. Utworzenie drugiego klienta dla tego samego klucza kończy się błędem configuration_error. To kolejny powód, by tworzyć klienta tylko raz.

Wyślij i znajdź testowy log

Wywołaj verifyLogBrewSetup() raz z testowej akcji dostępnej tylko w wersji deweloperskiej. Poczekaj na wynik i obsłuż odrzucony promise. Nie wypisuj klucza ani paczki zdarzeń. Wynik 2xx z batches większym niż 0 pokazuje, że LogBrew przyjął paczkę. Puste opróżnienie kolejki zwraca 204 z 0 prób i 0 paczek, bo automatyczne dostarczanie mogło wysłać zdarzenie wcześniej. W obu przypadkach odczytaj zapisany log w CLI:
Sprawdź w wyniku czas zdarzenia i usługę. Pusty wynik nie pokazuje przyczyny. Sprawdź projekt, klucz i zakres czasu. RecordingTransport.alwaysAccept() służy tylko do testów lokalnych. Zwraca syntetyczne 202 i nie wysyła żadnego żądania.

Dostarczanie offline i po restarcie

Odczytaj client.deliveryHealth().storage w działającej aplikacji:
  • persistent: klient używa natywnej kolejki. Oczekujące zdarzenia ładują się ponownie po restarcie aplikacji.
  • memory: oczekujące zdarzenia giną, gdy środowisko uruchomieniowe JavaScript się restartuje.
Domyślne persistentQueue: "auto" używa natywnej kolejki, gdy plik binarny aplikacji zawiera natywny moduł LogBrew. Expo Go i starsze pliki binarne używają kolejki w pamięci. Aktualizacja samego JavaScriptu nie doda natywnego modułu. Jeśli aplikacja produkcyjna potrzebuje dostarczania po restarcie, ustaw persistentQueue: "required". Wtedy tworzenie klienta kończy się błędem configuration_error, gdy brakuje natywnej kolejki. Zbuduj aplikację ponownie z natywnym modułem. Używaj persistentQueue: "disabled" tylko wtedy, gdy chcesz mieć kolejkę w pamięci. Natywna kolejka mieści najwyżej 1000 zdarzeń i 4 MiB danych zdarzeń. Obowiązują też mniejsze limity klienta. Zdarzenia w natywnej kolejce zachowują swoje ID po restarcie. Dostarczanie działa w trybie „co najmniej raz”, więc ponowienie może wysłać zdarzenie dwa razy. Gdy ID i treść zdarzenia pasują do zdarzenia, które LogBrew już przyjął, LogBrew nie zapisuje go ponownie. Opróżnienie kolejki w tle to próba, a nie dowód dostarczenia. Przetestuj rejestrowanie offline i restart aplikacji. Potem znajdź zapisane zdarzenie w projekcie.

Odczytaj stan dostarczania

client.deliveryHealth() zwraca stan kolejki i dostarczania bez treści zdarzeń. Najpierw odczytaj te pola:

Wybierz treść logu

Każdy komunikat powinien być krótki i konkretny. Opisz wynik w aplikacji, na przykład nieudane żądanie albo zaplanowane ponowienie. Nie umieszczaj imion i nazwisk, adresów e-mail, tokenów dostępu, wartości formularzy ani treści żądań. Użyj poziomu ważności, który pasuje do zdarzenia: info, warning, error lub critical. Usługa, środowisko i wydanie powinny być spójne, aby dało się znaleźć powiązane wpisy. npx react-native log-ios i npx react-native log-android pokazują lokalne logi urządzenia. Nie odpytują LogBrew. Zobacz Debugowanie kodu natywnego w React Native.

Napraw nieudane sprawdzenie

Nieudane flush() odrzuca promise z kodem błędu SDK. Nie umieszczaj kluczy ani treści zdarzeń w raportach błędów. Więcej sprawdzeń opisuje strona Rozwiązywanie problemów.

Zachowaj Debug ID z Expo w pakietach wydania

Utwórz konfigurację Metro dla Expo przez LogBrew. Wtedy pakiet uruchomieniowy dostaje to samo Debug ID co jego mapa źródeł (source map):
Jeśli aplikacja używa trybu pakietu React Native Worklets, zastosuj tę transformację po funkcji pomocniczej LogBrew:
Funkcja pomocnicza zachowuje istniejące wtyczki Expo działające przed serializacją. Aplikacja w czystym React Native zamiast tego opakowuje gotową konfigurację Metro w withLogBrewMetroConfig(). Nie używaj tego opakowania z Expo. W przeciwnym razie build produkcyjny zatrzyma się z komunikatem, który wskazuje getLogBrewExpoConfig().