А если страниц например 800, и на всех разные элементы на которых vh, разово можно отловить ? что бы не писать для кждого элемента медиа запросы

значит у тебя хуево всё

Ну ок, держи ситуацию, все жлементы формы (включая тултипы) должны ресайзится в зависимости от высоты экрана

>font-size: 4vh O_O

Ну ок, держи ситуацию, все жлементы формы (включая тултипы) должны ресайзится в зависимости от высоты экрана

хуйня какая-то... честно

так ни один адекватный человек не сделает

максимум @media по высоте для html { font-size }

и уже юзать rem

Советую взять рамду

И там есть evolve

Советую взять рамду

тянуть еще одну либу ради какого-то метода ?

я бы посоветовал разбить на 2 редюсера просто и потом скомбайнить

Советую взять рамду

для такого простого не нужно

return evolve({ list: reject(equals(action.text)) }, state)

Ну так у него такого много может быть

reject можно заменить на without([ action.text ])

тянуть еще одну либу ради какого-то метода ?

Если я начинаю писать что-то на редаксе, то все равно рано или поздно полрамды заюзывается

Мало того, тянуть из рамды можно только один метод, если что

А для чего вы пишете редюсеры ?

А для чего вы пишете редюсеры ?

обновлять стор

Разбить на два редьюсера это да, нужно, если что

ну просто у меня почти 80% апы это модули для редюсеров или реюз hoc редюсеров

и для тех 20% которые очень специфические тянуть что-то для обновления стейта не особо надо.

Какой action creator юзать или в них нет смысла?

больше всего работать с данными нужно в селекторах и эпиках

Но without, union, evolve, dissoc и assoc/assocPath я часто использую в редьюсера для нормализованных данных

Народ подскажите пожалуйста, что вы используйте для ajax запросов в react?

Потому что нужно обновить и данные, и индексы

axios подойдёт?

da

Есть блок #container, в нем текст на котором висит свойство font-size: 4vh, как можно сделать что бы когда высота экрана была например меньше 600 текст переставал ресайзится

https://habrahabr.ru/post/310186/

Вот это тот момент, когда я уже не понимаю, зачем тянуть зависимость, когда есть fetch

Но without, union, evolve, dissoc и assoc/assocPath я часто использую в редьюсера для нормализованных данных

да, ramda прикольная штука, оосбенно хорошо, что она не мутирует стейт, но у меня почти всегда в бандле есть lodash от redux-form, так что тянуть рамду туда не особо хочется

Вот это тот момент, когда я уже не понимаю, зачем тянуть зависимость, когда есть fetch

мидлвары, отмена реквеста, статус реквеста ?

А, ну вот. Я просто не использую lodash и полностью заменил его рамдой

Вот это тот момент, когда я уже не понимаю, зачем тянуть зависимость, когда есть fetch

Сова тебе объяснит, зачем

Сова тебе объяснит, зачем

а че сова? я юзаю fetch

но когда нужно отловить 300 редирект он идет нахуй единственный эдж кейс

Вооот

но когда нужно отловить 300 редирект он идет нахуй единственный эдж кейс

А отмена реквестов как и кеширование ?

А отмена реквестов как и кеширование ?

кеширование сам отмена реквестов, эм нахрен это надо

кеширование сам отмена реквестов, эм нахрен это надо

Когда делается много однотипных запросов и надо отменить предыдущий если он еще пендинг и сделать новый

takeLatest с саги по сути

Ну или switchmap в rx

но это уже рх

запрос то останется

запрос то останется

от от

просто ответ уже не будут обрабатывать

Когда делается много однотипных запросов и надо отменить предыдущий если он еще пендинг и сделать новый

тут нужно решать на уровне приложения а не отменять запросы запросы нельзя отменить

Можно)

Отмена запроса это по сути игнорирование ответа

но когда нужно отловить 300 редирект он идет нахуй единственный эдж кейс

а в чем проблема? у респонса же есть status

Игнорирование со стороны приложения или браузера - не так важнт

Если ответ не вызывает экшона, то для меня его и нет

Игнорирование со стороны приложения или браузера - не так важнт

Не тратятся браузерные ресурсы на обработку респонса

Отмена запроса это по сути игнорирование ответа

нет отмена запроса это отмена (abort)

Ну так запрос-то уже все равно обычно ушел на сервер

а в чем проблема? у респонса же есть status

fetch не так работает у него защита есть от этого 300 статусы не ловятся а сразу follow запрос если делаешь manual nо не получаешь нормального response

еще привет бекенду если у вас живой поиск или тип того

хотя это можно через delay частично решить

Ну так запрос-то уже все равно обычно ушел на сервер

на серовер да но ответ уже не придет - игнорировать нечего

хотя это можно через delay частично решить

debounce

fetch не так работает у него защита есть от этого 300 статусы не ловятся а сразу follow запрос если делаешь manual nо не получаешь нормального response

всмысле если {redirect: 'manual'} в конфиге передать по респонсу не понятно какой статус редиректа?

всмысле если {redirect: 'manual'} в конфиге передать по респонсу не понятно какой статус редиректа?

response пустой будет с статусом opaqueRedirect

debounce

Окей, у нас живой поиск, мы делаем реквест, потом еще один и что бы ок работало, то нам надо скипнуть предыдущий реквест и обработать, только второй. (с  axios это просто вызвать метод cancel), как с фетчем решить эту проблему ?

Окей, у нас живой поиск, мы делаем реквест, потом еще один и что бы ок работало, то нам надо скипнуть предыдущий реквест и обработать, только второй. (с  axios это просто вызвать метод cancel), как с фетчем решить эту проблему ?

debounce

ERROR: S client not available

и что ?

По идее запросы с дебоунсом не могут иметь мусорных респонсов

респонс от первого реквеста идет дольше чем от второго

response пустой будет с статусом opaqueRedirect

хм судя по спеке opaqueredirect это type у response а не статус... ну я не сталкивался, не буду спорить

респонс от первого реквеста идет дольше чем от второго

не отправлять запрос сразу же а ждать

Потому что ненужные запросы даже не выполнятся

хм судя по спеке opaqueredirect это type у response а не статус... ну я не сталкивался, не буду спорить

да, ты прав type перепутал

но status: 0

не отправлять запрос сразу же а ждать

т.е ждать пока прийдет респонс от предыдущего реквеста ?

Как-то выглядит не особо быстро

будет игра в багнутый поиск

будет игра в багнутый поиск

хдд

запрос новый респонс старый

а потом уже новый

т.е ждать пока прийдет респонс от предыдущего реквеста ?

блядь DEBOUNCE ты НЕ ДЕЛАЕШЬ запрос Ты вызываешь функцию которая должна будет сделать запрос через 500мс если не будет вызвана снова (например)

Так а если респонс идет 1 секунду ?

т.е ждать пока прийдет респонс от предыдущего реквеста ?

НЕ ОТПРАВЛЯТЬ ЗАПРОСУ СРАЗУ ЖЕ!

та не ори ты

дебаунс включен

но решает траблу частично

тебе об этом говорят

на хайлоаде такое не прокатит

поиск с фильтрами через всю дб

и что

И ВСЕ

блин делал такое вообще проблем не было

я тогда даже не знал что у axios есть .cancel()

да abort нужен фетчу, пока только хаками можно отменить

аборт есть у xmlhttprequest :)

например делать запрос в вебворкере а при отмене закрывать его лол

вот тут обсуждение https://github.com/whatwg/fetch/issues/447

да abort нужен фетчу, пока только хаками можно отменить

единственный кейс когда нужно было знать порядок и отменять результаты старого запроса я решал номером запросов