То есть мы переходим уже к организации бизнес-логики? Для неё у нас Flux. Не Redux, но одна из вариаций реализации концепции. Всё общение с сервером там. Общая логика приложения в хранилищах. Взаимодействие с состоянием других компонентов тоже через них. Компоненты имеют и параметры, и внутреннее состояние. Компоненты нужны для визуализации и взаимодействия с пользователем, а для этого нужно в правильных дозах использовать и то, и другое.
В общем, понятно — однонаправленное изменение данных, события и подписки, никто никуда не стучится.
Компоненты не должны быть обязательно stateless. Внутренее состояние надо использовать, но использовать с умом. Всё, что касается внутренней логики компонента, должно происходить внутри него. Из хранилищ должна приходить общая картина приложения, состояния других компонентов, информация от сервера и т.д. Некоторые внутренние вещи даже не обязательно в state хранить. Локальные переменные класса никто не запрещает. State нужен только для той внутренней логики, которая сама вызывает перерисовку компонента. Компоненты совсем без состояния в большинстве случаев можно заменить на «тупые» функциональные компоненты.
Нам React позволяет создавать такие блоки, на страницах, которые могут «постоять за себя», но при этом легко встраиваются в произвольную среду за счёт параметризации. И это поведение наслаивается. Компонент не обязательно является финальной точкой в дереве, он часто разбивается на более мелкие составляющие, которые в свою очередь могут быть применены в других аналогичных родительских компонентах. То есть до определённого момента мы параметризируем и переиспользуем родителя, а в сложных ситуациях можем создавать альтернативные блоки переиспользовать детей.
И не стоит забывать, что часть компонентов отвечает за визуализацию, а часть за логику (и вперемешку тоже). Визуальные компоненты чаще всего будут stateless и очень просто интегрируются в нужное место. Они же чаще являются функциональными компонентами, чья задача — «пережевать» пропы и выдать результат.
Я ответил: со старого стэка. Нюансы этого стэка к сути какого-либо аргумента не относятся. Там были свои компоненты, полноценный MVC и всё, что с этим связано. Я нигде не сказал, что мы перешли откуда-то, где было плохо с компонентами и композицией. Я только обратил внимание, что заявление автора о невозможности переиспользовать компоненты в сложном проекте ошибочно. Потому что у нас это успешно получается уже больше года.
Всё зависит от Вашей специфики. Мы торгуем. У нас есть элементы, вроде корзины покупателя или формы оплаты, которые можно встраивать в разные контексты и получать единое настраиваемое представление. Я не знаю, что Вы хотите мне доказать, потому что я не своё мнение описываю, а с чем имею дело в работе. Я нигде не сравнивал React ни с чем, не говорил, что он лучшее решение из имеющихся в индустрии. Только лишь указал, какие его «минусы» по мнению автора вызвали у меня негодование. Часть этих минусов от непрочтения документации автором. А тот, к которому прицепились вы, вообще является преимуществом технологии. Не над чем-то преимуществом, а в целом — то, что записывают в графу «Плюсы».
В общем, если Вы хотите посравнивать и поспорить, я в это влезать не буду, уж простите.
Мы обновляли свой стэк на более современный по тем или иным причинам. И выбрали React потому, что с ним очень удобно делать независимые блоки в композиции приложения и использовать их в любом месте. Я лишь привёл свой анекдотичный опыт прямо отрицающий категоричную позицию автора о том, что React для этого непригоден.
Сколько же в тексте желтухи и некорректных утверждений.
Компоненты React трудно использовать повторно в сложных веб-проектах.
Разрабатываем и поддерживаем интерактивный фронтэнд для большого и сложного проекта. Успешно переиспользуем компоненты. Callback'и есть только в качестве обработчиков событий у дочерних компонент (прямо как в натуральном DOM). Всё очень хорошо выходит.
Получилось, правда, не с первой итерации, но всему же надо учиться. Повторное использование компонент повлияло как раз на переход к React, это вообще одно из его основных преимуществ. Вся логика, связанная с контекстом использования, контролируется через пропы, и это очень наглядно.
Веб-разработчики вынуждены использовать свойство key, а также методы shouldComponentUpdate и componentWillUpdate, чтобы помочь фреймворку угадать правильно.
Свойство key служит ключом при сортировке элементов, а хуки помогают корректно и только при необходимости обновлять компонент. Ведь пропы могут содержать довольно сложные структуры! Конечно, разработчик должен не бездумно подходить к созданию своего кода, находить места для оптимизации.
К сожалению, поддержка HTML в React является неполной. Разработчик должен вручную заменить class на classname, а for на htmlFor.
Автор, кажется, даже не открывал документацию и совсем не понял, что такое JSX и зачем оно нужно. Эх…
В WebStorm, если ничего не поменялось, даже SSH-расширение включать отказались. Хотя, казалось бы, NodeJS давно поддерживается, нужно как-то работать с удалёнными серверами, тот же PHPStorm это всё прекрасно допускает… Но нет, в WebStorm не хотим (официальный ответ поддержки в Твиттере был). А Вы про базы данных…
Да, можно. Но всё таки комментарии к тикетам — не основная функция JIRA, и прикручивать для этого почтового бота и авторизацию по ссылкам — как-то убийственно для небольшого бонуса. И что должен делать бот, например, при ответе на письмо о тикете, в котором закрыты комментарии? Писать эту ошибку в ответном сообщении? Получается целый интерфейс для работы через почту. А тут всё же система со своим замкнутым workflow, которым логично пользоваться напрямую.
Да и не по теме статьи это — статья о том, что за любым отправленным письмом должен быть ответственный человек, к которому можно обратиться ответным письмом. Ваша идея к связи с человеком не приведёт.
Думаю, Aclz тут больше имел ввиду банальное письмо из какой-нибудь системы, на вроде JIRA. Мол, новая заявка, вот ссылка, дальше разбирайтесь там. То есть в Вашем примере человеку правильно зайти в систему и указать свои претензии там.
У вас округление координат при изменении масштаба сбоит. В результате на уровне, когда транспорт отображается мелкими точками, маршруты двигающиеся по Ленинскому проспекту отображаются по сторонам от него, в том числе посреди Нескучного сада.
А в остальном на удивление точно. Вот бы ещё данные были доступны для всех разработчиков, а не только для Яндекса.
1.7.10 всё действительно по-старому. Оптимизации были добавлены в последних снэпшотах 1.8. Судя по эффектам, они научили движок не рисовать бОльшую часть невидимых глазу блоков, а также перешли на VBO.
1.8, кстати, уже вышел. Можно обновиться и попробовать.
Я понимаю, о чем был комментарий выше, но я не придерживаюсь политики «Демо через пиратство». Мое отношение к вопросу: проблемы таких игроков равносильны критике реплики картины за небрежность.
Я не предлагаю никаких запретов, я считаю нужным воспитывать в людях понятие об ответственности. И Вы правы, уважение, как и поддержку, без договора никто не обязан оказывать. У компании есть право отказать таким пользователям, и я не вижу в этом чего-то неправильного.
В общем, понятно — однонаправленное изменение данных, события и подписки, никто никуда не стучится.
Нам React позволяет создавать такие блоки, на страницах, которые могут «постоять за себя», но при этом легко встраиваются в произвольную среду за счёт параметризации. И это поведение наслаивается. Компонент не обязательно является финальной точкой в дереве, он часто разбивается на более мелкие составляющие, которые в свою очередь могут быть применены в других аналогичных родительских компонентах. То есть до определённого момента мы параметризируем и переиспользуем родителя, а в сложных ситуациях можем создавать альтернативные блоки переиспользовать детей.
И не стоит забывать, что часть компонентов отвечает за визуализацию, а часть за логику (и вперемешку тоже). Визуальные компоненты чаще всего будут stateless и очень просто интегрируются в нужное место. Они же чаще являются функциональными компонентами, чья задача — «пережевать» пропы и выдать результат.
Всё зависит от Вашей специфики. Мы торгуем. У нас есть элементы, вроде корзины покупателя или формы оплаты, которые можно встраивать в разные контексты и получать единое настраиваемое представление. Я не знаю, что Вы хотите мне доказать, потому что я не своё мнение описываю, а с чем имею дело в работе. Я нигде не сравнивал React ни с чем, не говорил, что он лучшее решение из имеющихся в индустрии. Только лишь указал, какие его «минусы» по мнению автора вызвали у меня негодование. Часть этих минусов от непрочтения документации автором. А тот, к которому прицепились вы, вообще является преимуществом технологии. Не над чем-то преимуществом, а в целом — то, что записывают в графу «Плюсы».
В общем, если Вы хотите посравнивать и поспорить, я в это влезать не буду, уж простите.
Разрабатываем и поддерживаем интерактивный фронтэнд для большого и сложного проекта. Успешно переиспользуем компоненты. Callback'и есть только в качестве обработчиков событий у дочерних компонент (прямо как в натуральном DOM). Всё очень хорошо выходит.
Получилось, правда, не с первой итерации, но всему же надо учиться. Повторное использование компонент повлияло как раз на переход к React, это вообще одно из его основных преимуществ. Вся логика, связанная с контекстом использования, контролируется через пропы, и это очень наглядно.
Свойство key служит ключом при сортировке элементов, а хуки помогают корректно и только при необходимости обновлять компонент. Ведь пропы могут содержать довольно сложные структуры! Конечно, разработчик должен не бездумно подходить к созданию своего кода, находить места для оптимизации.
Автор, кажется, даже не открывал документацию и совсем не понял, что такое JSX и зачем оно нужно. Эх…
Да и не по теме статьи это — статья о том, что за любым отправленным письмом должен быть ответственный человек, к которому можно обратиться ответным письмом. Ваша идея к связи с человеком не приведёт.
А по существу: изменения — всегда хорошо.
А в остальном на удивление точно. Вот бы ещё данные были доступны для всех разработчиков, а не только для Яндекса.
1.8, кстати, уже вышел. Можно обновиться и попробовать.
Я не предлагаю никаких запретов, я считаю нужным воспитывать в людях понятие об ответственности. И Вы правы, уважение, как и поддержку, без договора никто не обязан оказывать. У компании есть право отказать таким пользователям, и я не вижу в этом чего-то неправильного.