Мы пару лет назад пришли точно к такому же решению, но вот есть один момент, который отличается и хочу обратить на него ваше внимание.
tuiGenerateDialogableRoute - принимает только два нужных параметра — компонент и путь.
Не уверен, что этот подход хорош, т.к. на самом деле, существует еще множество параметров, которые нужны. Например Resolver, либо же guard.
У нас хелпер принимает интерфейс Route из angular/route, тем самым мы не ограничиваем разработчика своими обертками, а лишь помогаем ему в реализации его планов.
Вот сами притащили реакт в ангуляр, а теперь прыгают с разбега на грабли и матюкаются)))
Нет, на самом деле, я верю в потенциал ngrx и реакт модели и не важно где это, в ангуляре или у черта лысого применено, важно лишь то, что человек, который это использует должен отдавать себе отчет в том что он делает. Ведь не сам код прибился гвоздями и не ангуляр его прибил, правильно же?) Ведь все зависит от того, как код писался, насколько гибко, сколько раз программист подумал прежде чем его написать.
Плохой, не поддерживаемый и не переносимый код можно написать на любом языке/фреймворке. Я как человек достаточное время работающий в аутсорс разработке не понаслышке знаю о внезапно меняющихся требованиях, иногда, будь они прокляты, координально меняющихся, но я не помню чтобы я в это время при возникновении трудностей винил инструмент. Я винил только себя за то, что поленился и не продумал момент. И уж тем более я не помню нерешаемых проблем, хотя нужно отметить, что я сталкивался с подобным кодом, который писали индусы, там впринципе проще сделать
rm -rf ./project_dir
mkdir project_dir
start coding
Потому что индусы ребята конечно очень способные в этом плане)
На практике разработчикам приходится прибегать к чудесами изобретательности для того, чтобы заставить приложение на Angular делать то, что не является частью фреймворка.
Эту цитату можно применить к любому фреймворку на мой взгляд, рано или поздно разработчик сталкивается с таким, но это «рано или поздно» может наступить совсем не скоро, либо не наступить вовсе. Ведь как известно, наши заказчики люди с оооочень богатой фантазией…
Это может привести к сложности поддержки проектов, если базовые принципы, на которых они основаны, не были чётко сформулированы в самом начале их разработки. На практике разработчикам приходится прибегать к чудесами изобретательности для того, чтобы заставить приложение на Angular делать то, что не является частью фреймворка.
Хоть один пример бы, а то чувствую себя слепым и ущербным теперь.
Мы полагаем
, так вы полагаете или вы хотя бы hello world написали?
Дмитрий, спасибо за статью!
Мы пару лет назад пришли точно к такому же решению, но вот есть один момент, который отличается и хочу обратить на него ваше внимание.
tuiGenerateDialogableRoute - принимает только два нужных параметра — компонент и путь.
Не уверен, что этот подход хорош, т.к. на самом деле, существует еще множество параметров, которые нужны. Например Resolver, либо же guard.
У нас хелпер принимает интерфейс Route из angular/route, тем самым мы не ограничиваем разработчика своими обертками, а лишь помогаем ему в реализации его планов.
Что думаете?
Нет, на самом деле, я верю в потенциал ngrx и реакт модели и не важно где это, в ангуляре или у черта лысого применено, важно лишь то, что человек, который это использует должен отдавать себе отчет в том что он делает. Ведь не сам код прибился гвоздями и не ангуляр его прибил, правильно же?) Ведь все зависит от того, как код писался, насколько гибко, сколько раз программист подумал прежде чем его написать.
Плохой, не поддерживаемый и не переносимый код можно написать на любом языке/фреймворке. Я как человек достаточное время работающий в аутсорс разработке не понаслышке знаю о внезапно меняющихся требованиях, иногда, будь они прокляты, координально меняющихся, но я не помню чтобы я в это время при возникновении трудностей винил инструмент. Я винил только себя за то, что поленился и не продумал момент. И уж тем более я не помню нерешаемых проблем, хотя нужно отметить, что я сталкивался с подобным кодом, который писали индусы, там впринципе проще сделать
rm -rf ./project_dir
mkdir project_dir
start coding
Потому что индусы ребята конечно очень способные в этом плане)
Эту цитату можно применить к любому фреймворку на мой взгляд, рано или поздно разработчик сталкивается с таким, но это «рано или поздно» может наступить совсем не скоро, либо не наступить вовсе. Ведь как известно, наши заказчики люди с оооочень богатой фантазией…
Хоть один пример бы, а то чувствую себя слепым и ущербным теперь.
, так вы полагаете или вы хотя бы hello world написали?