b7
Что тут за "пусть говорят"? дочки сестры братья...
Пджи. Щас выяснится, что это не дочь вовсе, а сын. Мы только начали
Size: a a a
2020 July 18
BB
Утверждение что это кривая архитектура релевантно только если это controlled
V
я недавно слайдер делал используя только эту либу, в целом все хорошо вышло
там же еще ивенты подымать https://react-dnd.github.io/react-dnd/docs/backends/touch гиги
И
Если стэйт используется только внутри конкретного компонента и его дочек, тот тут и редакс не нужен. Внутри компонента useState, на дочерние - контекст.
А если дочек полторы тысячи на трёх сотнях уровней вложенности?)
И
почему?
Потому что это бессмысленно
Л
Потому что это бессмысленно
я немного не понял что именно, использовать некоторым компонентам свой редюсер или что? Разве не так мы должны делать?
K
там же еще ивенты подымать https://react-dnd.github.io/react-dnd/docs/backends/touch гиги
я если честно хз что это, у меня ssr и я никакие ивенты не поднимал
b7
А если дочек полторы тысячи на трёх сотнях уровней вложенности?)
Контекст?
V
я если честно хз что это, у меня ssr и я никакие ивенты не поднимал
а как? HOC useDrag в нем логика + анимация и по ней управляешь положением элемента?
И
я немного не понял что именно, использовать некоторым компонентам свой редюсер или что? Разве не так мы должны делать?
Мы должны создавать редьюсеры исходя из логики приложения. Из бизнес-логики. Из того, как используются данные, какие это данные, как они связаны друг с другом.
Компоненты и вьюхи — это сущности, которые пользуются стором, а не наоборот, как в оригинальном вопросе, когда компоненты говорят стору, как хранить данные.
Если ты для страницы юзера написал редьюсер, который знает всё про эту страницу, потом написал для страницы постов редьюсер, который знает всё про посты, ты красавчик. Через две недели пришла задача: нужно на странице постов выводить данные про юзера. Что делать? Данные про юзера уже есть в редьюсере другой страницы, можно просто взять из него селектором, так ведь? Через месяц все страницы смотрят во все редьюсеры. И где структура? Как объяснить новичку на проекте, что страница настроек тянет данные из пяти «редьюсеров других страниц», кроме «ну бля, удобно вроде было»
Я вообще не понимаю, что тут неочевидно и что тут можно обсуждать
Компоненты и вьюхи — это сущности, которые пользуются стором, а не наоборот, как в оригинальном вопросе, когда компоненты говорят стору, как хранить данные.
Если ты для страницы юзера написал редьюсер, который знает всё про эту страницу, потом написал для страницы постов редьюсер, который знает всё про посты, ты красавчик. Через две недели пришла задача: нужно на странице постов выводить данные про юзера. Что делать? Данные про юзера уже есть в редьюсере другой страницы, можно просто взять из него селектором, так ведь? Через месяц все страницы смотрят во все редьюсеры. И где структура? Как объяснить новичку на проекте, что страница настроек тянет данные из пяти «редьюсеров других страниц», кроме «ну бля, удобно вроде было»
Я вообще не понимаю, что тут неочевидно и что тут можно обсуждать
И
Контекст?
А нахера стейт-менеджеры придумали?
Л
Мы должны создавать редьюсеры исходя из логики приложения. Из бизнес-логики. Из того, как используются данные, какие это данные, как они связаны друг с другом.
Компоненты и вьюхи — это сущности, которые пользуются стором, а не наоборот, как в оригинальном вопросе, когда компоненты говорят стору, как хранить данные.
Если ты для страницы юзера написал редьюсер, который знает всё про эту страницу, потом написал для страницы постов редьюсер, который знает всё про посты, ты красавчик. Через две недели пришла задача: нужно на странице постов выводить данные про юзера. Что делать? Данные про юзера уже есть в редьюсере другой страницы, можно просто взять из него селектором, так ведь? Через месяц все страницы смотрят во все редьюсеры. И где структура? Как объяснить новичку на проекте, что страница настроек тянет данные из пяти «редьюсеров других страниц», кроме «ну бля, удобно вроде было»
Я вообще не понимаю, что тут неочевидно и что тут можно обсуждать
Компоненты и вьюхи — это сущности, которые пользуются стором, а не наоборот, как в оригинальном вопросе, когда компоненты говорят стору, как хранить данные.
Если ты для страницы юзера написал редьюсер, который знает всё про эту страницу, потом написал для страницы постов редьюсер, который знает всё про посты, ты красавчик. Через две недели пришла задача: нужно на странице постов выводить данные про юзера. Что делать? Данные про юзера уже есть в редьюсере другой страницы, можно просто взять из него селектором, так ведь? Через месяц все страницы смотрят во все редьюсеры. И где структура? Как объяснить новичку на проекте, что страница настроек тянет данные из пяти «редьюсеров других страниц», кроме «ну бля, удобно вроде было»
Я вообще не понимаю, что тут неочевидно и что тут можно обсуждать
а тю, так да
K
а как? HOC useDrag в нем логика + анимация и по ней управляешь положением элемента?
не хок, а хук, в общем создаешь переменную с помощью этого хука, ее передаешь элементу что нужно отслеживать, а хук будет давать инфу куда там пальцем влево вправо водят, и на сколько пикселей, он никак ничего не анимирует, только дает инфу когда тачи идут
Л
я ж говорю, не так понял, абсолютно верно, извиняйте
V
есть лучше этого swiperjs.com ???
V
не хок, а хук, в общем создаешь переменную с помощью этого хука, ее передаешь элементу что нужно отслеживать, а хук будет давать инфу куда там пальцем влево вправо водят, и на сколько пикселей, он никак ничего не анимирует, только дает инфу когда тачи идут
скок весит это удовольстве как можно быстро узнать?
V
для меня это оч критикал… зачем то решили использовать реакт (ну отчасти из-за меня) для рисования важное семантик верстки
DK
скок весит это удовольстве как можно быстро узнать?
И
скок весит это удовольстве как можно быстро узнать?
