• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Fetch owinięty w new Promise

Aruba Cloud - Virtual Private Server VPS
+1 głos
179 wizyt
pytanie zadane 10 sierpnia 2019 w JavaScript przez Kamil M Bywalec (2,340 p.)
edycja 10 sierpnia 2019 przez Kamil M

Cześć,
Mam pytanie dotyczące fetch. Przerabiam pewien kurs i koleś zrobił coś takiego: 

class EasyHTTP {
    get(url) {
        return new Promise((resolve, reject) => {
            fetch(url)
                .then(response => response.json())
                .then(data => resolve(data))
                .catch(error => reject(error));
        });
    }
}

const http = new EasyHTTP;

http.get('https://jsonplaceholder.typicode.com/users')
     .then(data => console.log(data))
     .catch(reason => console.log(Error(reason)));

Czy istnieje jakiś powód, dla którego powinno się owijać fetch w new Promise? Przecież fetch sam w sobie zwraca promise. Przerobiłem to na coś takiego i w praktyce też działa:

class EasyHTTP {
    get(url) {
        return fetch(url)
            .then(response => response.json())
            .then(data => data)
            .catch(reason => Error(reason));
    }
}

const http = new EasyHTTP;

http.get('https://jsonplaceholder.typicode.com/users')
    .then(data => console.log(data))
    .catch(reason => console.log(Error(reason)));

 

À propos programowania obiektowego. Czy nie lepszym rozwiązaniem byłoby tutaj wykorzystanie statycznych metod skoro klasa i tak nie ma konstruktora?

1
komentarz 10 sierpnia 2019 przez BT101 Stary wyjadacz (12,540 p.)

Ten 1 fragment kodu to deferred antipattern

2 odpowiedzi

0 głosów
odpowiedź 10 sierpnia 2019 przez adrian17 Mentor (352,580 p.)
wybrane 10 sierpnia 2019 przez Kamil M
 
Najlepsza

Czy istnieje jakiś powód, dla którego powinno się owijać fetch w new Promise?Przecież fetch sam w sobie zwraca promise. 

Raczej nie. Jeszcze fajniej byłoby to przepisać z async/await.

 Czy nie lepszym rozwiązaniem byłoby tutaj wykorzystanie statycznych metod skoro klasa i tak nie ma konstruktora?

Być może jeszcze lepszym byłyby zwykłe wolne funkcje ;)

komentarz 10 sierpnia 2019 przez Kamil M Bywalec (2,340 p.)

Dzięki za odpowiedź smiley Czy coś takiego jest bardziej poprawne?

class EasyHTTP {
    static async get(url) {
        try {
            const response = await fetch(url);
            const json = await response.json();
            return json;
        } 
        catch(reason) {
            return Error(reason);
        }
    }
}

Co do wolnych funkcji to zawsze mam mindfuck. Teoretycznie dużo rzeczy można robić wolnymi funkcjami bez używania OOP. Tak naprawdę kiedy piszę coś sam z siebie to rzadko odczuwam potrzebę używania konstruktorów i innych cudów. Może za mało jeszcze zakodowałem, żeby używać ich w odpowiednich sytuacjach laugh

0 głosów
odpowiedź 10 sierpnia 2019 przez Selfie Początkujący (440 p.)
Cześć! Nie. Pozdrawiam!!

Podobne pytania

0 głosów
0 odpowiedzi 147 wizyt
+1 głos
1 odpowiedź 1,394 wizyt
pytanie zadane 7 maja 2018 w JavaScript przez Kacper Łochowski Początkujący (270 p.)
0 głosów
1 odpowiedź 832 wizyt
pytanie zadane 28 kwietnia 2017 w JavaScript przez moofi Początkujący (470 p.)

93,329 zapytań

142,323 odpowiedzi

322,400 komentarzy

62,662 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj

Wprowadzenie do ITsec, tom 1 Wprowadzenie do ITsec, tom 2

Można już zamawiać dwa tomy książek o ITsec pt. "Wprowadzenie do bezpieczeństwa IT" - mamy dla Was kod: pasja (użyjcie go w koszyku), dzięki któremu uzyskamy aż 15% zniżki! Dziękujemy ekipie Sekuraka za fajny rabat dla naszej Społeczności!

...