А то что надо (удобно в перспективе) писать так чтобы легко менялось и дополнялось — это и так все знают
Да все знают, что так надо делать, но большинство не знают как) большинство не знают, как выглядит инверсия зависимости в коде) Поэтому это первая статья из цикла, про то что это важно (следующее видео на эту тему уже опубликовано, а расшифровка опубликуется позже), а немного позже будет и статья полный разбор реальной задачи
чет не получается нормально отформатировать :(
`
const Item = ({ index, text }) => {
const ref = useRef()
useEffect(() => {
const size = ref.current.getBoundingClientRect()
// тут делай все что надо тебе с size, можешь родителю прокинуть sendToParent(size)
}, [])
return (
div ref={ref} className="phraseWrapper"{index + ' ' + text} div
)
}
}
`
ну тут разные подходы есть. Первый и самый просто это вынести item в отдельный компонент и в нем сделать классический useRef() и таким образом оно создаст для каждого компонента свой ref и все будет работать ок. Я думаю этого варианта будет достаточно
Но если вдруг тебе надо более сложную конструкцию, тогда я рекомендую сразу это видео посмотреть, чтобы хорошо понимать исходники как они работают: youtu.be/hoQz95Fh84c
И когда ты будешь осознавать, почему создается объект и зачем нужен current внутри него, ты сможешь улучшить реализацию
Тут конечно надо видеть весь код и иметь возможность с ним поэксперементировать. Для начала я бы рекомендовал не передавать функцию в ref. Т.к. на каждый рендер вы отправляете новую функцию
это относится к попапам, хоть и косвенно. Если ты работаешь с попапами через единый менеджер попапов, тогда ты обретаешь проблему где хранить эти попапы и хороших вариантов как хранить 50 попапов я не вижу, какие есть варианты:
1. хранить в виде flat list в одном месте — тут мы уже все сошлись, что это неудобно
2. хранить в одном месте но поделить их по доменам, чуть лучше, но все равно проблема остается, что у тебя будут в некоторых доменах богом забытые попапы
3. хранить не в одном месте, а рядом с тем кодом где попап и вызывается — в таком случае у менеджера попапов будут импорты по всему проекту, да еще и глубокие импорты, это все надо поддерживать на дистанции, ну такое как по мне
Я как раз таки отказался от такого подхода. Видел много раз такое как раз таки с промисами. Зависающие промисы тоже как по мне звучит не очень. Ты открыл попап и пока заполняешь форму, промис висит все это время. Хотя есть способы как не создавать эти промисы бесмысленно.
Вторая проблема почему я отказался, это то что если все попапы хранить в одном месте их там собирается иногда больше 50. И ты уже не особо ориентируешь, какие еще используются, какие легаси и управлять этим становится сложнее
Третья проблема, это например ты создаешь пользователя в попапе, и один из пунктов это загрузить аватарку, по требованиям при загрузке фото нужно скрыть прошлый попап и показать попап с кропом картинки, а после кропа вернуть в прежний попап с прежними данными. В итоге из-за того что оба эти попапа контекстные, у меня нет проблем с хранением состояние между переключающимися попапами
Таких примеров с неудоствами можно много перечислять, это лишь первые которые я вспомнил из своего опыта. Каждый попап требует индивидуального подхода, по крайней мере мне такая идеология нравится
У меня целая отдельная философия с попапами. Я их делю на группы и по разному их открываю. И есть глобальные попапы, как вы и говорите храним их глобально ближе к корню. Но есть и контекстные попапы (я так их называю). Которые принадлежат конкретной странице. Самым простым примером. Вы хотите удалить пользователя и вам показывают попап «А вы уверены?». И получается, если его открывать глобально, тогда нужно этому попапу пробросить все данные в случае, если пользователь нажмет «Да, удалить». Либо какой-то колбек туда пробросить. А потом если вы удалите эту страницу, тогда высокая вероятность, что вы забудете удалить этот попап. И другие мелкие преимущества. Поэтому иногда в этом есть смысл.
Все верно) в следующей статье планировал дозакрывать вопросы про мемоизации ссылки объекта и рассуждений на тему альтернативного варианта использования useMemo)
В этой хотел лишь показать, что любые вычисления не стоит мемоизировать, для многих это очевидно, но как показывает практика, далеко не для всех
> Я бы не учил новичков мешать разные подходы. У них и так часто каша в голове. Статья должна либо учить React и React-way, либо учить plain JavaScript. Это моё мнение.
React написан на JS как тут можно их не мешать я не очень представляю)
Да и контент который я публикую, он никак не направлен на новичков. Для новичков и так курсов / уроков / статей пруд пруди. А вот для senior разрабов контента порассуждать не хватает. Собственно поэтому я и начал свою деятельность.
Спор дальнейший не вижу особого смысла продолжать :) очевидно что мы оба останемся при своем мнении)
очень интересная имплементация)
мы тоже пишем на mobX, но с хуками мучаемся во ViewModel)
Возможно себе возьмем на вооружение какие то подходы)
Спасибо!)
Да все знают, что так надо делать, но большинство не знают как) большинство не знают, как выглядит инверсия зависимости в коде) Поэтому это первая статья из цикла, про то что это важно (следующее видео на эту тему уже опубликовано, а расшифровка опубликуется позже), а немного позже будет и статья полный разбор реальной задачи
Мне кажется вы все говорите об одном и том же, только разными словами)
не за что :)
чет не получается нормально отформатировать :(
`
const Item = ({ index, text }) => {
const ref = useRef()
useEffect(() => {
const size = ref.current.getBoundingClientRect()
// тут делай все что надо тебе с size, можешь родителю прокинуть sendToParent(size)
}, [])
return (
div ref={ref} className="phraseWrapper"{index + ' ' + text} div
)
}
}
`
Но если вдруг тебе надо более сложную конструкцию, тогда я рекомендую сразу это видео посмотреть, чтобы хорошо понимать исходники как они работают: youtu.be/hoQz95Fh84c
И когда ты будешь осознавать, почему создается объект и зачем нужен current внутри него, ты сможешь улучшить реализацию
1. хранить в виде flat list в одном месте — тут мы уже все сошлись, что это неудобно
2. хранить в одном месте но поделить их по доменам, чуть лучше, но все равно проблема остается, что у тебя будут в некоторых доменах богом забытые попапы
3. хранить не в одном месте, а рядом с тем кодом где попап и вызывается — в таком случае у менеджера попапов будут импорты по всему проекту, да еще и глубокие импорты, это все надо поддерживать на дистанции, ну такое как по мне
Вторая проблема почему я отказался, это то что если все попапы хранить в одном месте их там собирается иногда больше 50. И ты уже не особо ориентируешь, какие еще используются, какие легаси и управлять этим становится сложнее
Третья проблема, это например ты создаешь пользователя в попапе, и один из пунктов это загрузить аватарку, по требованиям при загрузке фото нужно скрыть прошлый попап и показать попап с кропом картинки, а после кропа вернуть в прежний попап с прежними данными. В итоге из-за того что оба эти попапа контекстные, у меня нет проблем с хранением состояние между переключающимися попапами
Таких примеров с неудоствами можно много перечислять, это лишь первые которые я вспомнил из своего опыта. Каждый попап требует индивидуального подхода, по крайней мере мне такая идеология нравится
В этой хотел лишь показать, что любые вычисления не стоит мемоизировать, для многих это очевидно, но как показывает практика, далеко не для всех
в следующий вторник видео опубликую) а позже скорей всего и статью по нему напишу)
ждите!)
React написан на JS как тут можно их не мешать я не очень представляю)
Да и контент который я публикую, он никак не направлен на новичков. Для новичков и так курсов / уроков / статей пруд пруди. А вот для senior разрабов контента порассуждать не хватает. Собственно поэтому я и начал свою деятельность.
Спор дальнейший не вижу особого смысла продолжать :) очевидно что мы оба останемся при своем мнении)
мы тоже пишем на mobX, но с хуками мучаемся во ViewModel)
Возможно себе возьмем на вооружение какие то подходы)
Спасибо!)