А на "почему?" отвечают, что варнинг вываливается.

Просто правда на анмаунт пофиг, но все топят за запросы в редаксе.

в мидлваре редакса

в мидлваре редакса

Не суть.

А на "почему?" отвечают, что варнинг вываливается.

Тебе ответили почему

Просто правда на анмаунт пофиг, но все топят за запросы в редаксе.

Ну потому что логику выносишь отдельно. Потом у тебя ещё один компонент будет делать то же самое, будешь копипастить?

Тестирование с помощью di делается.

/s/di/костылей/

Ну потому что логику выносишь отдельно. Потом у тебя ещё один компонент будет делать то же самое, будешь копипастить?

Ну, для этого есть сервисы.

/s/di/костылей/

Ну, фиг знает.

Ну потому что логику выносишь отдельно. Потом у тебя ещё один компонент будет делать то же самое, будешь копипастить?

Так я в любом случае для каждого контейнера буду их прописывать

Ок, спасибо за ответы.

Вот логику ещё понял. Экшены для этого контейнера коннектятся в этом контейнере. А вот насчёт копипаста не понял

Вот логику ещё понял. Экшены для этого контейнера коннектятся в этом контейнере. А вот насчёт копипаста не понял

Дважды данные тянуть и всё такое.

кейс: - логин кнопка отправляет запрос (только последний, отправляет сразу) - логаут отменяет запрос могут быть в разных частях посмотри https://redux-saga.js.org/docs/recipes/ как разрулить таоке внутри компонентов (опять, могут быть в разных частях приложения)

Дважды данные тянуть и всё такое.

То есть при каждом вызове connect(state => state)(Container) он будет перезаписывать уже имеющиеся, а при mapstatetoprops просто добавляться в имеющиеся?

кейс: - логин кнопка отправляет запрос (только последний, отправляет сразу) - логаут отменяет запрос могут быть в разных частях посмотри https://redux-saga.js.org/docs/recipes/ как разрулить таоке внутри компонентов (опять, могут быть в разных частях приложения)

У тебя есть сервис, который работает с этим. Хотя по идее это и есть редакс, но как-то избыточным выглядит.

То есть при каждом вызове connect(state => state)(Container) он будет перезаписывать уже имеющиеся, а при mapstatetoprops просто добавляться в имеющиеся?

тут больше логика создания "умных" компонентов: которые знают ЧТО делают тупые, но ни как они выглядят передавая стейт - тупой сам решает как ему работать

Проще написать небольшой класс, который будет этим заниматься.

Или у редакса есть огромное преимущество по сравнению с сервисами?

Потому что у сервисов хотя бы есть нормальная типизация.

Или у редакса есть огромное преимущество по сравнению с сервисами?

когда кода становится достаточно, чтобы стрелять по ногам - да, есть преимущества

когда кода становится достаточно, чтобы стрелять по ногам - да, есть преимущества

Можешь конкретизировать? А то для меня как-то не очевидно.

Можешь конкретизировать? А то для меня как-то не очевидно.

а теперь представь, что сервисы должны между собой общаться...

а теперь представь, что сервисы должны между собой общаться...

Представил. di)

Медиатор паттерн знаешь?

там базовый пример с самолетами и диспетчерской вышкой

Нет, гляну. Спасибо.

Медиатор паттерн знаешь?

Т.е. это общепринятый стандарт на фронте, верно?

Т.е. это общепринятый стандарт на фронте, верно?

просто хорошая практика, загугли "GOF patterns"

Есть что-то плохого в этом способе?

Я не хочу импортировать отдельно каждый компонент, а просто import { Button } from './components';

Это общепринятая практика.

отлично! спасиб.

Пока до динамических импортов не дойдёшь

Что ты под ними подразумеваешь?

я, чтобы править не двух местах, а только в одном, деаю чуть менее красиво export { default as Container } from "./Container" export { default as Input } from "./Input"

Что ты под ними подразумеваешь?

У этого термина нет разночтений

import()

А ещё лучше от дефолтных импортов отказаться

Сфигаль?)

я отказываюсь потиху, они какие-то костыльные)

рефакторить много приходится с дефолтными

причем тут cjs

Нафиг

я, чтобы править не двух местах, а только в одном, деаю чуть менее красиво export { default as Container } from "./Container" export { default as Input } from "./Input"

export * from './name'

не сработает в его случае, у компонентов экспорт же дефолтный, откуда жс имя возьмет)

Потому что то же самое получится почти) в конце файла пишешь export {myFunc1, myFunc2, ...}

Потому что то же самое получится почти) в конце файла пишешь export {myFunc1, myFunc2, ...}

Что мешает напротив const/function писать export?

Ничего... мне просто больше нравится, когда экспорт в одном месте (сразу видно весь интерфейс)

Ничего... мне просто больше нравится, когда экспорт в одном месте (сразу видно весь интерфейс)

Жесть

А auth0 для авторизации вообще кто-нибудь использует или в этом нет особого смысла?

Сфигаль?)

Провоцируют неконсистентность в именовании дефолтных импортов. Приходится форсить одновременно и чтобы экспортируемая сущность имела имя, и чтобы при импорте это имя соответствовало Когда над проектом работает овер 50 человек, такие мелочи становятся важны

Есть и другие причины, но они больше субъективны

Провоцируют неконсистентность в именовании дефолтных импортов. Приходится форсить одновременно и чтобы экспортируемая сущность имела имя, и чтобы при импорте это имя соответствовало Когда над проектом работает овер 50 человек, такие мелочи становятся важны

Тут соглашусь

Тоже чаще юзаю именованные

мы щас потихоньку выпиливаем дефолтные тоже

главный минус - с ними рефакторинг не работает

в новном проекте использую только именованные. Помню, год назад фыркал на ангуляр, что там по стайлгайду не используют дефолтные

и вообще зачем 2 способа делать одно и то же

еще бы поменять наоборот синтаксис

я был бы доволен

from 'react' import { React }

теоретически можно бабелем решить

но IDE охуеет

from 'react' import { React }

Чет не

import 'foo'

Тогда отличия начинаются

нормально

Не

в питоне так

у меня пусть лучше отличия иногда будут

чем всегда

import 'react' { React, Component }

import "react" (React, Component) як у хаскеле Все равно там {} нифига не деструктуринг

from 'react' import { React }

Это бы было идеально

import "react" (React, Component) як у хаскеле Все равно там {} нифига не деструктуринг

Вот в моем синтаксисе так. Правда я не знал, что в хаскеле так

import 'foo'

что это должно делать?

Вот в моем синтаксисе так. Правда я не знал, что в хаскеле так

Так тоже идеально

так сделали чтобы было аналогично с присвоением переменных и Object Destruction .. let { a, b } = c; import { React } from 'react';

что это должно делать?

то же, что делает сейчас, выполняет сайд-эффект модуля, если он есть)

from 'react' import module

:)

(я покрайней мере такую аргументацию слышал)

Главное, чтобы сначала было написано, откуда, а потом уже - что Хоть автоподстановка была бы

import Data.Map (fromList)

Главное, чтобы сначала было написано, откуда, а потом уже - что Хоть автоподстановка была бы

да

что это должно делать?

Просто импортит Как require('foo')

Так. Я правильно понимаю, что есть те, кто отказался от дефольтных импортов ПОЛНОСТЬЮ?

Так. Я правильно понимаю, что есть те, кто отказался от дефольтных импортов ПОЛНОСТЬЮ?

почти

в процессе