Ну надоедает же все эти константы экспортировать и тд

можно, createAction('SOME_NAME', dispatch => dispatch). Точнее то что я написал бред. Но это сделать можно, в экшине доступен диспатч и его можно отдать как пэйлоад

хм, какой то хак получается

Пишешь одно и тоже

тупо dispatch({type: “23123”, …data})?

Почему никто не создаёт onClick эвенты самостоятельно но при этом не смущается описывать втупую эвенты редакса?)

redux ducks никто не юзает?

redux ducks никто не юзает?

Юзают

Но по сути это ничего не меняет

Юзают

и шо и как

В плане писанины экшонов

event = action action = action creator action creator = non sense type constant = non sense

Я пока сделал так вызов экшена fetchUser который по сути является обычным () => dispatch => {} а в нем уже дальше вызываю экшены созданные через redux-actionы

Я пока сделал так вызов экшена fetchUser который по сути является обычным () => dispatch => {} а в нем уже дальше вызываю экшены созданные через redux-actionы

Это санки

event = action action = action creator action creator = non sense type constant = non sense

В итоге мы заменяем четыре концепции на две, одну из которых даже не используем напрямую

при вызове fetchUser диспатчу уже fetchUserRequest

Это санки

да

Можно просто сделать свою мидл вару

event = action action = action creator action creator = non sense type constant = non sense

угу

взяли систему ивентов и нахуя-то понапридумывали имен

vanilla js ещё жив к 17 году, или уже устарел?

жив

Можно просто сделать свою мидл вару

хотел решить как проще

)))

vanilla js ещё жив к 17 году, или уже устарел?

Типа es6+ это уже не ванильный ?

Как-то натыкался на список CSSinJS библиотек в GitHub'е, у кого-нибудь нет такой ссылочки в закромах?

Как-то натыкался на список CSSinJS библиотек в GitHub'е, у кого-нибудь нет такой ссылочки в закромах?

Стайлед или jss

Отчего такой ворнинг может быть?

Стайлед или jss

Там их было много

Второй раз спрошу

Как-то натыкался на список CSSinJS библиотек в GitHub'е, у кого-нибудь нет такой ссылочки в закромах?

могу даже скинуть на презу этого чувака

Там их было много

Остальные так себе

Как-то натыкался на список CSSinJS библиотек в GitHub'е, у кого-нибудь нет такой ссылочки в закромах?

https://github.com/MicheleBertoli/css-in-js

https://github.com/MicheleBertoli/css-in-js

Йе, спасибо!

https://github.com/tuchk4/awesome-css-in-js

можешь еще его презу на ютубе посмотреть

давольно-таки интересно

Ток малех устарела, в плане сравнений

это да

в июне преза была записана

или июле

Мне сейчас кажется, что понимание связанности последовательности импортов аналогично по сложности пониманию квантовой механики

или июле

нь

Окей, что делать, если моя цепочка импортов не работает

Это же жесть

Мне больше всего нравится styled-jss, но там медленно разработка идет... Кто что может посоветовать? (styled-components не предлагать, мне нужно в js объекте стили писать).

Мне кажется написать врапер, который будет пробрасывать объект со стилями и функциями в SC дело одного часа

Но, может, есть какие подводные камни. Хотя я вот подумал пол минуты, вроде нет

Но, может, есть какие подводные камни. Хотя я вот подумал пол минуты, вроде нет

Хок пишется

И кидает стили как пропсы в sc

А, в attrs можно

ы

нет

Уникальность ключа должна оставаться независимо от количества перерендеров

Как в таком случае поступить, сгенерить их в constructor или componentWillMount сохранив в this.keys и потом использовать в render?

Ну тут тебе только index юзать

Ну тут тебе только index юзать

Нет

ERROR: S client not available

Нельзя ключи массива юзать

А что может быть уникального у списка 1-10 :)

Нельзя ключи массива юзать

Можно, но не нужно Вроде же так

я вот лично столкнулся с проблемой когда использовал i вместо уникального key. в результате использования i получилось так что реакт не понимал какой компонент удалился и вешал стиль на совершенно другой.

Можно, но не нужно Вроде же так

Ну можно и стейт мутировать

Если так рассуждать

так что по поводу такого решения, адекватно?

Как в таком случае поступить, сгенерить их в constructor или componentWillMount сохранив в this.keys и потом использовать в render?

так что по поводу такого решения, адекватно?

Главное чтобы ключ был уникальным и не менялся в зависимости от количества элементов (поэтому ключ массива не подходит)

Короче при получении данных где-то мэпом добавь ключи и все

изменять props же нельзя)

изменять props же нельзя)

А у тебя элементы списка получают свои же данные?

uuid

Нельзя ключи массива юзать

Можно если пересортировки не будет

Можно если пересортировки не будет

Так себе подход

@danSteshenko а если один объект удалиться? все что за ним получат не достовернный key

@danSteshenko а если один объект удалиться? все что за ним получат не достовернный key

тогда будет ре рендер

и ключи будут новые

там при сортировках начинаются проблемы

Так себе подход

Нормальный подход если сортировки нет

Нормальный подход если сортировки нет

https://medium.com/@robinpokorny/index-as-a-key-is-an-anti-pattern-e0349aece318

@danSteshenko я тоже так думал, но в том то и суть что при ре рендер использует ключи что бы запускать componentUpdate избегая полного цикла создания нового компонента.

As a last resort, you can pass an item’s index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.

Из доки

Reconciliation

As a last resort, you can pass an item’s index in the array as a key. This can work well if the items are never reordered, but reorders will be slow.

ты на 100% можешь быть уверен

что не будешь фильровать

ты на 100% можешь быть уверен

Ты хотел сказать, должен быть уверен?