Не бывает «некуда уходить». Бывает только «страшно». Просто начинайте смело работать над своим желанием лучшего. Заставьте себя хотеть перемен. Убедите себя в том, что иного выхода, кроме как двигаться вперед у вас тупо нет. Прямо так – или я тут в конце концов сопьюсь (утрированно), или я стану крутым парнем из столицы. Никто, вообще никто не держит вас на месте, кроме вас самих. Поймите это, и все потихонечку начнет двигаться.
Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.
Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.
С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
Может я что-то делаю не так, но ваше решение не работает (будьте осторожны JS уйдет в глубокий нимб после запуска).
У меня было решение без именных функций сродни вашему, но там возникает проблема иного рода, а именно нужно чуть более усердно думать об очистке за собой. Поэтому решение с именными функциями мне показалось наиболее оптимальным, так после себя ничего не оставляет. С этим примером можно в этом убедиться.
Но я никак не могу понять, что вы хотите сказать/доказать?
Что react знает больше людей? Очевидно.
Что я покусился на святое? Я уже ответил Вам ниже, что никто react «уделывать» не собирается.
Что react и подобное нужно использовать везде (даже в до безобразия маленьких проектах)? Весьма и весьма спорный тезис.
Что не нужно / нельзя / запрещено искать собственные решения для тех или иных задач? А как же тогда тот же react на свет появился? До него, что не было альтернатив? А как быть с нашим Яндексом? Уж сколько он «пилит» своих решений. Он тоже плохой?
Или может вы считаете, что если некий проект сделан на react, то его с ходу «прочитает» любой сторонний разработчик? Да, нет. Все также придется какое-то время сидеть и разбираться, что к чему.
Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.
Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.
То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.
У меня, конечно, то еще самомнение, но в одиночку противопоставлять себя замечательным, талантливым и умным ребятам, создавшим react?
Нет, я никого не хочу «уделывать». И если вы посмотрите на мой предыдущий пост об этом шаблонизаторе, то увидите, как яростно я отказывался сравнивать шаблонизатор вообще с чем-либо. Во-первых, не время – не все еще готово из задуманного. Во-вторых, и концепция от части может поменяться.
Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.
Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.
Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.
Что же касается минификации, то этот вопрос все еще открыт. Думаю, над ним. Технически объединение шаблонов не проблема. Но есть ряд иных вопросов, связанных с тем, как вставляет контент в разметку шаблонизатор, что мешает идти, скажем так, простым и накатанным путем.
Спасибо за ваш вопрос и ваше время на эксперимент )
Ну на самом деле – это верный подход. Должны быть некие свойства/характеристики, которые отличают продукт от его конкурентов/аналогов.
Другое дело момент применения этого подхода. Когда продукт готов, его производитель не просто должен, а обязан выделять те самые «киллер-фитчи». Но вот на стадии разработки в этом нет острой необходимости.
Сейчас как раз она и есть, стадия разработки. Поэтому я могу дать (и даю) перечень идей, лежащих в основе продукта. Я могу повторить:
Избегание дополнительного окружения (библиотек, тулзов и прочего). Полная самодостаточность и возможность расширения функционала внутри решения со стороны разработчика. Это уже во многом реализовано. Flex.Patterns легко позволяет добавлять свой функционал к тому, что уже есть. Скажем вы «прицепились» к узлу, Flex.Patterns даст вам основной набор инструментов (ну там события прицепить, размеры снять, стили переопределить, анимацию применить и прочее). Но на ряду с этим у вас есть простой интерфейс для добавления своих инструментов к данному функционалу и, что очень важно, интегрировать эти вот свои инструменты внутрь Flex.Patterns – то есть делать свою собственную сборку конечного продукта.
Только стандартный синтаксис. Ну об этом я уже очень много говорил.
Хранение шаблонов и их ресурсов на клиенте.
Вот три идеи, которые на данный момент формируют вектор развития проекта. Но, а о «киллер-фитчах» мне пока говорить преждевременно.
Я бы не был столь категоричен. Да и нет здесь предмета спора.
Я особо не идеализирую решения, за которыми стоят (далее список) крупные команды и/или компании. От них сюрпризы случаются совсем нередко. Не стоит их идеализировать. То версию обновят так, что интерфейсы изменятся; то методы отрубят, которые раньше вполне себе работали. В результате для некрупного проекта, версия той или иной библиотеки попросту «замораживается», потому что переделывать все под очередное обновление выходит слишком дорого. В npm можно найти далеко не одно решение для каких-нибудь нужд, например, на базе react. Хорошие решения, грамотные. А запускаешь с последней версией react’a и сыплются в консоль «this method deprecated».
Поэтому если приходит заказчик и мы видим, что он сам еще толком не знает на какой именно результат ему рассчитывать, до конца не понимает (а порой и не верит) в успех своего проекта – да, мы настоятельно рекомендуем делать проще (не в ущерб бизнес-модели), чтобы как минимум посмотреть, пощупать и понять, как оно там будет. И чаще всего заказчик с нами соглашается.
Что же до топика, то описанный шаблонизатор как раз и задумывался как максимально упрощенный. Никакого дополнительного синтаксиса кроме стандартного HTML и JS. Как раз для того, чтобы сопровождение и/или мелкая коррекция проекта не вызывала особых трудностей.
Чуть выше в комментарии я рассказал с чего все началось (как этот шаблонизатор был выделен в отдельное решение). Оба тех проекта, где всецело применено это решение – это админки. То есть по существу – это одинаковый набор элементов управления, где разница есть в их компоновке и данных. В такой ситуации перенос представлений на клиента дал хороший результат. Первая загрузка подольше будет, зато вторая и последующие ощутимо шустрее. В свою очередь разбиение разметки на компоненты дало возможность их отладки в отрыве от приложения, что было очень удобным. Кроме того, после реализации первого проекта к началу работы над вторым уже была хорошая коллекция контролов, которые просто брали и использовали.
Таким образом, идея переноса представлений на клиента состояла в том, чтобы очень большую часть разметки, банально повторяющуюся от страницы к странице перенести на клиента. Перенеся все это на клиента, уменьшили отклик от сервера. А разбив все по элементам управления добились переносимости между подобными проектами.
Требования к мобильным устройствам в данных проектах практически не выставлялись, хотя и на них работает (но не тестировалось так глубоко и основательно, как десктоп).
Из всего спектра комментариев лишь одно дельное замечание, про экранирование (упущенное из виду). Спасибо.
На все остальное (там, где я проигнорировал) я могу ответить парой абзацев, потому как обсуждать, например, то, как проект выложен на github’е я смысла не вижу.
Я писал свое решение, не потому что других решений не существует, а потому что хотел разобраться как это работает. Для меня это здоровая (от слова здоровье) мотивация разработчика. И если собственник проекта не против экспериментов, то для программиста – это находка и глупость упускать подобный шанс; шанс понять, как оно работает изнутри; шанс проверить себя – смогу / не смогу сделать работящее самостоятельное решение. Не пригодится в будущем? Возможно. Кому-то не понравится? Конечно! Но, хвала Зевсу, для меня это не главное и практически не важно.
Видимо часть людей просто стала забывать, что разработка – это прежде всего творчество, искусство, возможность дать своей мысли форму. По крайне мере для меня – это именно так и именно по этой причине я пришел в эту профессию. Поэтому что я могу сказать? «Велосипедил» и буду «велосипедить» дальше, даже несмотря на то, что рядом лежит ReactJS, AngularJS, Jade, EJS и прочие тысячи инструментов.
Спасибо за комментарий. На это уйдет какое-то время, чтобы создать сопоставимые и наглядные примеры и «красиво привинтить» их к документации. Думаю, что неделя или две и я что-то подобное выложу.
Спасибо за комментарий.
Потому что тег TEMPLATE часть стандарта, а мне не хотелось свое «нестандартное» решение смешивать со стандартами. Однако в patterns предусмотрена простая возможность переопределения корневого тега шаблона.
Спасибо за ссылку. Почитал, очень интересно. У нас с вами разное целеполагание. У вас более глобально, что ли. У меня же все приземленно )). Моя задача была – шаблонизатор только для front-end.
Да, есть возможность вставки шаблонов в HTML, но опять же и сборка шаблона, и вся работа по его анализу – все на клиенте.
Кроме того, все началось с простой и банальной задачи. Я опишу, если позволите. Было приложение, со множеством разных «окошек» (админка в общем). И там была куча разных контролов. Почти все создавалось на серверной стороне. Потом пришла в голову мысль – а не перенести ли нам все это на клиента – нехай он сам парится, а на сервере все почистить, минимизировать и в идеале оставить только API. Посчитали количество контролов, вышли на несколько десятков очень простых элементов, которые могут работать автономно (то есть не зависят от какой-либо библиотеки и/или фреймвока). Тогда и пришла в голову мысль, а не распихать ли эти контролы по папочкам с JS и CSS, которые к ним относятся. Ну а на клиенте просто их подключать по мере необходимости.
В результате всего этого сервер стал передавать лишь базовую разметку, а вся рутина по рендерингу ушла на клиента вместе с нагрузкой. Мне не удалось, безусловно, превратить серверную часть просто в API сервис, но представлений с серверной стороны было убрано очень много. Ну разве что базовая разметка осталась, как я уже отметил.
Потом была еще пара подобных проектов, где перенос представлений на клиента прошел довольно успешно.
Ну а потом я решил, что пора это все привести в достойный вид (более ли менее) и выложить, может кому и полезным будет.
Иными словами, вот эта штука, которую я тут на ваш суд выставил – это такой инструмент, который позволяет представления вытаскивать с back-end на front-end. И главное, это позволяет проводить отладку каждого шаблона в отрыве от всего проекта. И такого рода инструмент он не универсален, безусловно, он для определенного круга задач.
Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
У меня было решение без именных функций сродни вашему, но там возникает проблема иного рода, а именно нужно чуть более усердно думать об очистке за собой. Поэтому решение с именными функциями мне показалось наиболее оптимальным, так после себя ничего не оставляет. С этим примером можно в этом убедиться.
Но я никак не могу понять, что вы хотите сказать/доказать?
Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.
Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.
То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.
Спасибо.
Нет, я никого не хочу «уделывать». И если вы посмотрите на мой предыдущий пост об этом шаблонизаторе, то увидите, как яростно я отказывался сравнивать шаблонизатор вообще с чем-либо. Во-первых, не время – не все еще готово из задуманного. Во-вторых, и концепция от части может поменяться.
Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.
Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.
Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.
Что же касается минификации, то этот вопрос все еще открыт. Думаю, над ним. Технически объединение шаблонов не проблема. Но есть ряд иных вопросов, связанных с тем, как вставляет контент в разметку шаблонизатор, что мешает идти, скажем так, простым и накатанным путем.
Спасибо за ваш вопрос и ваше время на эксперимент )
Другое дело момент применения этого подхода. Когда продукт готов, его производитель не просто должен, а обязан выделять те самые «киллер-фитчи». Но вот на стадии разработки в этом нет острой необходимости.
Сейчас как раз она и есть, стадия разработки. Поэтому я могу дать (и даю) перечень идей, лежащих в основе продукта. Я могу повторить:
Вот три идеи, которые на данный момент формируют вектор развития проекта. Но, а о «киллер-фитчах» мне пока говорить преждевременно.
Спасибо за ваш вопрос.
Я особо не идеализирую решения, за которыми стоят (далее список) крупные команды и/или компании. От них сюрпризы случаются совсем нередко. Не стоит их идеализировать. То версию обновят так, что интерфейсы изменятся; то методы отрубят, которые раньше вполне себе работали. В результате для некрупного проекта, версия той или иной библиотеки попросту «замораживается», потому что переделывать все под очередное обновление выходит слишком дорого. В npm можно найти далеко не одно решение для каких-нибудь нужд, например, на базе react. Хорошие решения, грамотные. А запускаешь с последней версией react’a и сыплются в консоль «this method deprecated».
Поэтому если приходит заказчик и мы видим, что он сам еще толком не знает на какой именно результат ему рассчитывать, до конца не понимает (а порой и не верит) в успех своего проекта – да, мы настоятельно рекомендуем делать проще (не в ущерб бизнес-модели), чтобы как минимум посмотреть, пощупать и понять, как оно там будет. И чаще всего заказчик с нами соглашается.
Что же до топика, то описанный шаблонизатор как раз и задумывался как максимально упрощенный. Никакого дополнительного синтаксиса кроме стандартного HTML и JS. Как раз для того, чтобы сопровождение и/или мелкая коррекция проекта не вызывала особых трудностей.
Чуть выше в комментарии я рассказал с чего все началось (как этот шаблонизатор был выделен в отдельное решение). Оба тех проекта, где всецело применено это решение – это админки. То есть по существу – это одинаковый набор элементов управления, где разница есть в их компоновке и данных. В такой ситуации перенос представлений на клиента дал хороший результат. Первая загрузка подольше будет, зато вторая и последующие ощутимо шустрее. В свою очередь разбиение разметки на компоненты дало возможность их отладки в отрыве от приложения, что было очень удобным. Кроме того, после реализации первого проекта к началу работы над вторым уже была хорошая коллекция контролов, которые просто брали и использовали.
Таким образом, идея переноса представлений на клиента состояла в том, чтобы очень большую часть разметки, банально повторяющуюся от страницы к странице перенести на клиента. Перенеся все это на клиента, уменьшили отклик от сервера. А разбив все по элементам управления добились переносимости между подобными проектами.
Требования к мобильным устройствам в данных проектах практически не выставлялись, хотя и на них работает (но не тестировалось так глубоко и основательно, как десктоп).
Из всего спектра комментариев лишь одно дельное замечание, про экранирование (упущенное из виду). Спасибо.
На все остальное (там, где я проигнорировал) я могу ответить парой абзацев, потому как обсуждать, например, то, как проект выложен на github’е я смысла не вижу.
Я писал свое решение, не потому что других решений не существует, а потому что хотел разобраться как это работает. Для меня это здоровая (от слова здоровье) мотивация разработчика. И если собственник проекта не против экспериментов, то для программиста – это находка и глупость упускать подобный шанс; шанс понять, как оно работает изнутри; шанс проверить себя – смогу / не смогу сделать работящее самостоятельное решение. Не пригодится в будущем? Возможно. Кому-то не понравится? Конечно! Но, хвала Зевсу, для меня это не главное и практически не важно.
Видимо часть людей просто стала забывать, что разработка – это прежде всего творчество, искусство, возможность дать своей мысли форму. По крайне мере для меня – это именно так и именно по этой причине я пришел в эту профессию. Поэтому что я могу сказать? «Велосипедил» и буду «велосипедить» дальше, даже несмотря на то, что рядом лежит ReactJS, AngularJS, Jade, EJS и прочие тысячи инструментов.
Еще раз спасибо за Ваше время.
Потому что тег TEMPLATE часть стандарта, а мне не хотелось свое «нестандартное» решение смешивать со стандартами. Однако в patterns предусмотрена простая возможность переопределения корневого тега шаблона.
Да, есть возможность вставки шаблонов в HTML, но опять же и сборка шаблона, и вся работа по его анализу – все на клиенте.
Кроме того, все началось с простой и банальной задачи. Я опишу, если позволите. Было приложение, со множеством разных «окошек» (админка в общем). И там была куча разных контролов. Почти все создавалось на серверной стороне. Потом пришла в голову мысль – а не перенести ли нам все это на клиента – нехай он сам парится, а на сервере все почистить, минимизировать и в идеале оставить только API. Посчитали количество контролов, вышли на несколько десятков очень простых элементов, которые могут работать автономно (то есть не зависят от какой-либо библиотеки и/или фреймвока). Тогда и пришла в голову мысль, а не распихать ли эти контролы по папочкам с JS и CSS, которые к ним относятся. Ну а на клиенте просто их подключать по мере необходимости.
В результате всего этого сервер стал передавать лишь базовую разметку, а вся рутина по рендерингу ушла на клиента вместе с нагрузкой. Мне не удалось, безусловно, превратить серверную часть просто в API сервис, но представлений с серверной стороны было убрано очень много. Ну разве что базовая разметка осталась, как я уже отметил.
Потом была еще пара подобных проектов, где перенос представлений на клиента прошел довольно успешно.
Ну а потом я решил, что пора это все привести в достойный вид (более ли менее) и выложить, может кому и полезным будет.
Иными словами, вот эта штука, которую я тут на ваш суд выставил – это такой инструмент, который позволяет представления вытаскивать с back-end на front-end. И главное, это позволяет проводить отладку каждого шаблона в отрыве от всего проекта. И такого рода инструмент он не универсален, безусловно, он для определенного круга задач.