Pull to refresh
6
0
Владимир Трояненко @non4me

User

Send message

Прошу прощения, почему то Хабра вместо продолжения, делает новые ветки и нет возможности это поправить.

Еще дополню для ясности.
Речь о том что все имеет свою цену и предлагаемый вами подход тоже. Вопрос в том если стоимость решения не превышает пользу. Я не уверен, что это оправдано для всего множества случаев. Что если мы просто одни проблемы меняем на другие. Особенно в контексте того что данный подход предлагается использовать как дефолтный.

Он должен обновляться потому что того например требует бизнес-логика. Я это привел просто как пример для более сложного случая.
Ладно, на этом пожалуй откланяюсь. Свою точку зрения я высказал. Возможно кому-то она покажется разумной.

Декомпозиция это само собой разумеющиеся вещь. Без этого вообще невозможно создание более мене сложного приложения. Я про то другое.
Как вы сами же пишете в статье при OnPush стратегии не обновляются параллельные ветки.
Таким образом скажем клик на кнопку в компоненте А в шапке страницы не будет автоматически обновлять компонент Б где нибудь в подвале поскольку они не находятся в одной ветке и вообще не связаны между собой напрямую. Соответсвенно нам нужно будет добавлять какую то дополнительную логику которая бы сообщила компоненту Б что ему требуется обновиться.
Именно это меня и смущает в подобном подходе. Поскольку очевидно ведет к усложнению и повышению хрупкости кода. Это накладные расходы которые нам требуется заплатить за предполагаемое повышение производительности. Причем не важно есть ли с ней проблемы или нет.
Поэтому подход, решать проблемы по мере возникновения, мне все же кажется более оптимальным.

Прочитал статью внимательно, но для меня OnPush так и остался способом для выборочного решения проблем с производительностью, а не дефолтным подходом. И вот почему.

Не считаете ли вы что использование данного подхода излишне усложняет проект? Появляется большое кол-во технического (не решающего бизнес-логику) кода только для того что бы по сути отказаться от одной из основных фишек фреймворка и поменять дефолтную стратегию (согласен, не всегда оптимальную) на собственный велосипед (тоже не оптимальный).
Есть ощущение что накладные расходы (особенной на сложных проектах) связанные с необходимостью поддержки подобного кода будут превышать профит.
Редизайн большого проекта с использованием подобного подхода вряд ли возможен. По сути, нам нужно разбить интерфейс на кучу несвязанных осколков и самостоятельно заботиться об их обновлении. Особенно тех что находятся в параллельных ветках.

Не совсем ясно причем тут RESTful.
RESTful это когда соблюдены все требования REST архитектуры. В том числе HATEOAS. А тут об этом даже не упоминается.
Самым популярным языком программирования является JavaScript. А вот язык PHP, судя по всему, с появлением Node и Angular попал в немилость.

Какое то странное предложение.
Как Angular может влиять на PHP и почему Node и Angular рассматриваются как самостоятельные языки. Не тот, ни другой языком не являются.
Да, прошу прощения, на заметил ярлык Перевод.
А вы не пробовали на странице с женской фотографией менять кнопки «Request a Demo» и «Try ClickTale» местами, а так же их цвет? Для того что бы убедится, что эффект сохраняется в независимости от других факторов.
Выше я уже писал о том, что при наличии языка пройти оригинальный курс будет так же полезно.
Но перевод делается для людей не знающих (или знающих недостаточно) язык с которого делается перевод. Это позволяет им сосредоточится именно на смысле материала, что для технических статей очевидно весьма полезно.
На чем именно основана ваша уверенность что просмотр видео смысл которого может быть не доконца ясен, гораздо лучше чем статья на родном языке? То что более 600 человек добавило статью в избранное и несколько поблагодарило в комментариях говорит скорее об обратном.

Кроме того, думаю, определенная часть читателей, которая раньше не слышала об замечательно ресурсе codeschool, посетило его и даже возможно оформила подписку. Так что скорее всего ребята из codeschool вряд ли останутся в накладе от перевода статьи которую они и так разместили в открытом доступе.

PS. Заранее хотелось бы избежать дискуссии, о том что знание английского языка крайне полезно (если не сказать необходимо) для айтишника. Я с этим и так полностью согласен.
Статья, в принципе, и является переводом данного курса. Но я так же постарался внести улучшения там, где, по моему мнению, это было уместно. Кроме того, это просто экономия времени. Выгоднее потратить полчаса на статью, чем два вечера, на прохождение курса.
Но если есть желание и возможность, то пройти оригинальный курс так же может быть полезным. С этим спорить не буду. Мне и самому очень нравиться как все реализовано на codeschool. Даже была там платная подписка одно время.
Прошу прощения у всех для кого принципиальным является именно грамматика. Возможно я слишком сосредоточился на переводе и не уделил этому достаточно внимания.
Кроме того, последние 9 лет я живу за пределами России, общаясь ежедневно на 3,5 языках, что не очень полезно с точки зрения каждого из них. Понимаю что это слабый аргумент, но тем не менее, иногда, даже в разговорной речи, возникают проблемы с русским языком.

Information

Rating
Does not participate
Location
Praha, Hlavni Mesto Praha, Чехия
Date of birth
Registered
Activity