Есть книжка Голдратта "Критическая цепь"(читал), и не помню автора "Вовремя и в рамках бюджета"(купил). Если вы читали их, то мне интересно ваше мнение о подходах, описанных в них.
В es6 есть WeakMap. Ключем является объект. Эта связь слабая, если сборщик мусора удалит объект, то map потеряет этот ключ. За счет этого память и не течет.
Вторая как раз про реакт. А т.к. объект функции будет тем же самым, то souldComponentUpdate корректно отработает.
Плюс там используется weak-map, по этому не будет проблем с мусором.
Цитата из последней книги Роберта Мартина: Clean Architecture.
A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles—it is not the SRP.
Historically, the SRP has been described this way: A module should have one, and only one, reason to change.
Software systems are changed to satisfy users and stakeholders; those users and stakeholders are the “reason to change” that the principle is talking about. Indeed, we can rephrase the principle to say this: A module should be responsible to one, and only one, user or stakeholder.
У компонента должна быть одна причина для изменения.
Причину формулирует роль на проекте.
Есть роль DBA и роль Аналитик. Так вот они вместе не должны требовать изменения одного компонента.
Посмотрите работы Роберта Мартина. Есть видео в clean coders, и книга Clean Architecture.
Is this a perfect scheme? Of course not. Might one kind of UI be so different from another that they couldn’t share a common interface? Of course that’s possible. Does that mean this kind of decoupling is a waste? Are you kidding me?
The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.
Никто не заставляет вас делать "универсальную абстракцию" БД или UI. Просто нужно сделать так, что бы БД или UI были плагинами к ядру. Естественно, этот интерфейс/абстракция располагается в ядре. Значит, этот интерфейс должен удовлетворять требованиям проекта. Если приложение работает с таблицами, то естественно, ему не подойдет Key/Value хранилище.
Я имел ввиду, что есть абстракция(интерфейс) "Ноги": "левую вперед", "правую вперед", и т.д.
А какие конкретно ноги — это приходит извне.
Это не тоже самое, что абстракция "Перемещатель". Где у "Перемещателя" есть метод переместить в точку. А "перемещателелем" могут быть и ноги и машина и самолет.
Соответственно, эта архитектура о том, что вы знаете, что вы управляете "Ногами", но какими именно не знаете.
Эта архитектура не про про переносимость.
Эта архитектура позволяет откладывать принятие решений.
Вы начинаете разрабатывать ваше приложение(бизнес логику) и постепенно формируете требования, например, у хранилища должны быть транзакции, нужна возможность полнотекстового поиска. Так вы сформулируете абстракцию хранилища. Естественно, вы будете оглядываться на существующие решения или их комбинации.
Эта архитектура про независимость от реализации, а не про независимость от абстракции. Еще раз: ядро будет зависеть от абстракции.
Ваше ядро будет знать, что вы работаете с чем-то MySQL подобным. Но не будет знать что это конкретно MySQL или заглушка с тем же интерфейсом, но хранящая данные в памяти.
Т.к. ядро зависит от MySQL-подобной абстракции, то не получится просто так перейти на другую абстракцию вроде Key-Value или EventSourcing.
Аналогично можно сказать и про UI и про все остальное.
Это работает только если вы все компоненты на rum делаете, а если нужно какой-то внешний реакт-компонент, то это не сработает. Нужен какой-то js движок: nodejs или nashorn
Я делаю проект-пример по работе с этой библиотекой, как раз покажу как с ресурсами работать.
Да, я видел эти библиотеки, спасибо.
Рендеринг через nashorn?
Рельсы используют «easy» подход, а clojure — «simple». Можно за это ругать рельсы, и многие упреки будут объективными, но можно взять из рельс лучшее, в частности роутинг. Если вы не сталкивались с rails, или есть какие-то предубеждения, то можно просто ознакомиться, как сделан роутинг у них — http://guides.rubyonrails.org/routing.html
Можно поштучно, как показано в этой статье. Можно пачкой, через bulk api. Если не хочется делать, используя бизнес логику, то можно обновлять все данные по расписанию.
Если вы знакомы с Clean Architecture и не боитесь Clojure, то стоит просмотреть мой проект
Может быть есть какая-то реализация шаблона Page Object для Puppeteer?
Есть книжка Голдратта "Критическая цепь"(читал), и не помню автора "Вовремя и в рамках бюджета"(купил). Если вы читали их, то мне интересно ваше мнение о подходах, описанных в них.
В es6 есть WeakMap. Ключем является объект. Эта связь слабая, если сборщик мусора удалит объект, то map потеряет этот ключ. За счет этого память и не течет.
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/WeakMap
Есть подход с мемоизацией.
https://github.com/timkendrick/memoize-weak
https://github.com/timkendrick/memoize-bind
Вторая как раз про реакт. А т.к. объект функции будет тем же самым, то souldComponentUpdate корректно отработает.
Плюс там используется weak-map, по этому не будет проблем с мусором.
Нужно весь раздел читать. Там есть примеры. По понятным причинам, я не могу его сюда вставить.
Цитата из последней книги Роберта Мартина: Clean Architecture.
Этот принцип неправильно трактуют.
У компонента должна быть одна причина для изменения.
Причину формулирует роль на проекте.
Есть роль DBA и роль Аналитик. Так вот они вместе не должны требовать изменения одного компонента.
Посмотрите работы Роберта Мартина. Есть видео в clean coders, и книга Clean Architecture.
https://github.com/darkleaf/quester/blob/master/src/cljc/quester/routes/web.cljc
так же вышла вторая переработанная версия библиотеки, с хорошими примерами
выпустил новую версию, полностью переработал библиотеку, добавил исчерпывающие примеры
https://github.com/darkleaf/router
https://8thlight.com/blog/uncle-bob/2011/11/22/Clean-Architecture.html
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
Никто не заставляет вас делать "универсальную абстракцию" БД или UI. Просто нужно сделать так, что бы БД или UI были плагинами к ядру. Естественно, этот интерфейс/абстракция располагается в ядре. Значит, этот интерфейс должен удовлетворять требованиям проекта. Если приложение работает с таблицами, то естественно, ему не подойдет Key/Value хранилище.
Я имел ввиду, что есть абстракция(интерфейс) "Ноги": "левую вперед", "правую вперед", и т.д.
А какие конкретно ноги — это приходит извне.
Это не тоже самое, что абстракция "Перемещатель". Где у "Перемещателя" есть метод переместить в точку. А "перемещателелем" могут быть и ноги и машина и самолет.
Соответственно, эта архитектура о том, что вы знаете, что вы управляете "Ногами", но какими именно не знаете.
Есть некоторое недопонимание у комментирующих.
Эта архитектура не про про переносимость.
Эта архитектура позволяет откладывать принятие решений.
Вы начинаете разрабатывать ваше приложение(бизнес логику) и постепенно формируете требования, например, у хранилища должны быть транзакции, нужна возможность полнотекстового поиска. Так вы сформулируете абстракцию хранилища. Естественно, вы будете оглядываться на существующие решения или их комбинации.
Эта архитектура про независимость от реализации, а не про независимость от абстракции. Еще раз: ядро будет зависеть от абстракции.
Ваше ядро будет знать, что вы работаете с чем-то MySQL подобным. Но не будет знать что это конкретно MySQL или заглушка с тем же интерфейсом, но хранящая данные в памяти.
Т.к. ядро зависит от MySQL-подобной абстракции, то не получится просто так перейти на другую абстракцию вроде Key-Value или EventSourcing.
Аналогично можно сказать и про UI и про все остальное.
Это работает только если вы все компоненты на rum делаете, а если нужно какой-то внешний реакт-компонент, то это не сработает. Нужен какой-то js движок: nodejs или nashorn
Я делаю проект-пример по работе с этой библиотекой, как раз покажу как с ресурсами работать.
Да, я видел эти библиотеки, спасибо.
Рендеринг через nashorn?
Конечно, спасибо за комментарии.
Действительно, зачем тут identity 9 раз написано?
это inline контроллер, а identity — обработчик-заглушка.
Это второй пример использования и я показываю другой вариант, в первом примере используется отдельный контроллер.
Макросы — это "темная магия" и без надобности ее применять не стоит. В данном случае все можно сделать через функции.
Конечно, в статье это упоминается, вот пример:
Можно поштучно, как показано в этой статье. Можно пачкой, через bulk api. Если не хочется делать, используя бизнес логику, то можно обновлять все данные по расписанию.
River стал deprecated.