«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
Как написал в комменте по другой ветке, имел ввиду Redux + e-commerce, но и на текущий вопрос могу ответить:
На данный момент повезло (или не очень) работать на проектах с AEM (бывший Adobe CQ), у этой платформы своя компонентная модель (java + jsp у CQ 5, и java + sightly у AEM), которая хранится в репозитории самой платформы и отдается как статика.
На данный момент есть небольшой опыт по использованию lodash+bbq+dust в одном проекте и BB (как набор моделей и некий pub\sub для общения) в другом.
По ощущениям BB использовать в текущих условиях приятнее: отсутствие кодогенерации из шаблонов при сборке дает преимущество во время разработки и отладки (не нужно делать редеплой, чтобы сгенерировать новый шаблон и залить его в репозиторий платформы и при необходимости можно непосредственно в репозитории сделать правку).
Компонентная модель реакта очень привлекательная, но в данном случае не очень применима: придется прикручивать компонентную модель одного фреймворка к компонентной модели другого, а это всегда чревато проблемами.
Прошу прощения, имел ввиду Redux, пока аппрувили коммент, истекло время для редактирования.
Для e-commerce в виде интернет-магазинов на много выгоднее использовать максимум статического контента для продвижения в поисковых выдачах. Идеальный вариант, это когда каждый продукт имеет свою собственную страницу, и поисковые выдачи можно оформлять как отдельные страницы (по крайней мере без ajax прогрузки первой страницы выдачи).
Подход старый, очень неприятный для многих современных разработчиков, но тем не менее более действенный.
SPA хоть и выглядит шикарно, но в данном случае для результата будет лучше использовать старые технологии. А прикручивать SPA стек там, где он не нужен, согласитесь, не лучшее решение.
Меня 1С, к счастью, тоже обошел стороной, но как знакомые на нем пишут видел, — читать базовые конструкции языка, не так тяжело (но с непривычки — не приятно), а вот бизнес логику воспринимать еще тяжелее. Вместо привычных репозиториев и DAO и прочего — там регистры, словари и прочее, но это уже больше DSL.
А для размышления, могу предложить идею, которой когда-то на первом курсе в университете баловался на С/С++ через макросы:
Даны целые А = 5, Б = 6. Вывести минимум от (А, Б). Вывести сумму (А, Б).
можно ради удовольствия попробовать развить эту идею =)
забавно и даже лучше, чем у коллеги из недавних постов)
но всегда, когда вижу такую русификацию вспоминается увиденный код в 1С: новый НТТРЗапрос() // ЭнТэТэЭр Запрос =)
как ни крути, все новые технологии и вся терминология появляется в англоязычном мире, и большинство термином даже сейчас не имеет адекватного перевода (а те, что имеют хоть какой-то — лучше бы не имели оного), поэтому любая локализация ЯП всегда будет сталкиваться с «суржиком».
на счет того, что статьи описывают идеи я понимаю, но ведь описано не очень хорошо, как писал раньше: то через апи, то через кишки (хотя, судя по тому, как пишут код в доках mobX — это их путь).
но хорошо, пойдем по пути документации: https://mobxjs.github.io/mobx/refguide/observable.html
аннотация/декоратор вешается только на массив, логично ждать срабатывания только, если изменится состояние структуры массива (добавили, удалили, заменили элементы).
но события публикуются и при изменении данных, которые лежат в массиве.
а соответственно, если необходимо изменить 2+ поля в данных — это породит 2+ событий, обойти это можно только если никогда не изменять данные, которые уже лежат в массиве: пересоздавать + перезаписывать данные.
> если вы начинаете додумывать и программировать в уме то делайте рефакторинг там же и подписывайтесь на конкретный todo
на конкретный туду — не исправит проблемы, зато кода будет в разы больше и он будет в разы хуже.
ps: а разве программировать можно как-то иначе, кроме как в уме? херяк-херяк, авось заработает — это плохой подход.
observableTodoStore.addTodo(«try MobX»);
observableTodoStore.todos[0].completed = true;
…
const store = observableTodoStore;
store.todos[0].completed = !store.todos[0].completed;
store.todos[1].task = «Random todo » + Math.random();
store.todos.push({ task: «Find a fine cheese», completed: true });
странный подход — то работать через апи, то прямо в кишки лезть…
а ведь если работать через апи класса, то неконсистентного состояния и быть не могло бы =)
В целом MobX привносит «магию» для замены простой концепции event dispatching (или pub/sub, если так приятнее).
Более того, если в апи добавить метод change, который будет изменять название и описание задания то, согласно коду выше, это породит 2 события изменения и изменение DOM произойдет 2 раза.
И это на примере кода уровня «hello world».
под этим подразумевал "Placement: None" в разделе Editor > General > Editor Tabs
но в целом, если Placement любой другой — результат тот же;
для обновленной Mac OS X до 10.11.4, эффек тот же; https://habrahabr.ru/company/JetBrains/blog/280019/#comment_8818523 чтобы не писать лишний коммент
при переходе из файла с кодом на проектные файлы (command + 1) и обратно (второй раз command + 1) не происходит возврата фокуса на редактор (может поможет: скрыты все табы)
часто/постоянно сворачивается дерево проекта в Project меню (для флеш проекта, при рефакторинге удаления файла или чего-то подобного, не сильно разбирался, для джава-проекта вроде нормально все)
«можно» — это еще не значит, что «будут».
при варианте с Redux Можно прикрутить jQuery и в обработчиках изменять DOM =)
Если возвести Абсурд в абсолют, можно слить абсолютно любую технологию.
А то, что сейчас называют спасением в виде Redux активно использовали еще до появления реакта в «мертвом» Flash =)
ps: а Redux разве еще не устарел?
На данный момент повезло (или не очень) работать на проектах с AEM (бывший Adobe CQ), у этой платформы своя компонентная модель (java + jsp у CQ 5, и java + sightly у AEM), которая хранится в репозитории самой платформы и отдается как статика.
На данный момент есть небольшой опыт по использованию lodash+bbq+dust в одном проекте и BB (как набор моделей и некий pub\sub для общения) в другом.
По ощущениям BB использовать в текущих условиях приятнее: отсутствие кодогенерации из шаблонов при сборке дает преимущество во время разработки и отладки (не нужно делать редеплой, чтобы сгенерировать новый шаблон и залить его в репозиторий платформы и при необходимости можно непосредственно в репозитории сделать правку).
Компонентная модель реакта очень привлекательная, но в данном случае не очень применима: придется прикручивать компонентную модель одного фреймворка к компонентной модели другого, а это всегда чревато проблемами.
Для e-commerce в виде интернет-магазинов на много выгоднее использовать максимум статического контента для продвижения в поисковых выдачах. Идеальный вариант, это когда каждый продукт имеет свою собственную страницу, и поисковые выдачи можно оформлять как отдельные страницы (по крайней мере без ajax прогрузки первой страницы выдачи).
Подход старый, очень неприятный для многих современных разработчиков, но тем не менее более действенный.
SPA хоть и выглядит шикарно, но в данном случае для результата будет лучше использовать старые технологии. А прикручивать SPA стек там, где он не нужен, согласитесь, не лучшее решение.
Если пользователю дать форму приведенную последней* он вас возненавидит! И ему будет плевать, что у вас там под капотом Крутой Реакт или Плохой-ББ ;-)
*- habrastorage.org/files/ec9/814/337/ec98143373b74e54820851c91d572901.png
А вот для формы из второго примера — без разницы какой фреймворк использовать, тут можно даже на Ванильном JS все сделать, будет даже быстрее =)
Ах, да, есть варианты, где React не уместен по тем или иным причинам: e-commerce, как вариант.
А для размышления, могу предложить идею, которой когда-то на первом курсе в университете баловался на С/С++ через макросы:
Даны целые А = 5, Б = 6. Вывести минимум от (А, Б). Вывести сумму (А, Б).
можно ради удовольствия попробовать развить эту идею =)
но всегда, когда вижу такую русификацию вспоминается увиденный код в 1С: новый НТТРЗапрос() // ЭнТэТэЭр Запрос =)
как ни крути, все новые технологии и вся терминология появляется в англоязычном мире, и большинство термином даже сейчас не имеет адекватного перевода (а те, что имеют хоть какой-то — лучше бы не имели оного), поэтому любая локализация ЯП всегда будет сталкиваться с «суржиком».
но хорошо, пойдем по пути документации: https://mobxjs.github.io/mobx/refguide/observable.html
аннотация/декоратор вешается только на массив, логично ждать срабатывания только, если изменится состояние структуры массива (добавили, удалили, заменили элементы).
но события публикуются и при изменении данных, которые лежат в массиве.
а соответственно, если необходимо изменить 2+ поля в данных — это породит 2+ событий, обойти это можно только если никогда не изменять данные, которые уже лежат в массиве: пересоздавать + перезаписывать данные.
> если вы начинаете додумывать и программировать в уме то делайте рефакторинг там же и подписывайтесь на конкретный todo
на конкретный туду — не исправит проблемы, зато кода будет в разы больше и он будет в разы хуже.
ps: а разве программировать можно как-то иначе, кроме как в уме? херяк-херяк, авось заработает — это плохой подход.
observableTodoStore.todos[0].completed = true;
…
const store = observableTodoStore;
store.todos[0].completed = !store.todos[0].completed;
store.todos[1].task = «Random todo » + Math.random();
store.todos.push({ task: «Find a fine cheese», completed: true });
странный подход — то работать через апи, то прямо в кишки лезть…
а ведь если работать через апи класса, то неконсистентного состояния и быть не могло бы =)
В целом MobX привносит «магию» для замены простой концепции event dispatching (или pub/sub, если так приятнее).
Более того, если в апи добавить метод change, который будет изменять название и описание задания то, согласно коду выше, это породит 2 события изменения и изменение DOM произойдет 2 раза.
И это на примере кода уровня «hello world».
расширение оной — плохой шаг в развитии языка.
кортеж — в целом не плохой вариант, но сильно увеличивает сложность восприятия кода, вот пример кода:
void DoSomeWith(int x, int y, int z);
DoSomeWith(target.vector);
теперь метод с тремя параметрами вызывается как метод с одним параметром — удобненько! *сарказм*
но в целом, если Placement любой другой — результат тот же;
для обновленной Mac OS X до 10.11.4, эффек тот же;
https://habrahabr.ru/company/JetBrains/blog/280019/#comment_8818523
чтобы не писать лишний коммент
Из ошибок, сразу встретил:
при переходе из файла с кодом на проектные файлы (command + 1) и обратно (второй раз command + 1) не происходит возврата фокуса на редактор (может поможет: скрыты все табы)
часто/постоянно сворачивается дерево проекта в Project меню (для флеш проекта, при рефакторинге удаления файла или чего-то подобного, не сильно разбирался, для джава-проекта вроде нормально все)