Задать вопрос
  • React + Redux. Как делать Dispatch древовидных данных чтобы отрендерился только вложенный компонент?

    @vintage
    onChange={(e)=>{this.props.dispatch(updateAnswer())

    Тут вы каждый раз создаёте новую функцию, что приводит к полному обновлению всего виртуального дома. Что лишний раз показывает бестолковость идеи виртуального дома, но это уже совсем другая история..
    Ответ написан
  • Как можно убрать "моргание" при перезагрузке страницы?

    @vintage
    Очевидно, вам нужна либо AJAX подгрузка контента, либо просто загрузка его во фрейме.
    Ответ написан
  • Почему Alight не реагирует на изменение состояния?

    @vintage
    Почему бы не спросить это у автора библиотеки? angularlight.org/community.html
    Ответ написан
    Комментировать
  • Фатальный недостаток nodejs, и стоит ли на это обращать внимание?

    @vintage
    Вы можете использовать node-fibers и забыть об этом фатальном недостатке.
    Ответ написан
    Комментировать
  • На что лучше перейти на Angular, React, Vue?

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

    Рассмотрим упомянутые варианты...

    AngularJS. JS. Он пляшет от шаблонов. В этом его сила (заверстали страницу, добавили директив и готово) и слабость (динамическое формирование страниц, как вы заметили, даётся с большим трудом). Криво реализованное двустороннее связывание и обнаружение изменений приводит к странным костылям и тормозам.

    Angular. TS. Опять же пляшет от шаблонов. Но внутрення архитектура улучшилась. С одной стороны она стала ещё сложнее, с другой - гибче. Динамику реализовать в нём проще, но придётся поломать голову ковыряясь в абстракциях. "Проталкивающая" модель реактивности не очень удобная и эффективная, но жить можно.

    Vue. JS. По уму сделанный AngularJS. Довольно практичный (если не пытаться прикручивать TS) с приятной "затягивающей" реактивностью. Из трендовых фреймворков я бы обратил внимание именно на него.

    React based. JS. Сам реакт - не более чем библиотека для рендеринга. Так что под его лейблом подразумевается на самом деле "мы написали свой фреймворк, в котором рендерим через реакт". Достаточно легко в нём реализуется динамика. Но с переиспользуемостью кода и его лаконичностью - просто беда. Куча копипасты во имя великой идеи с глобальным состоянием - типичная ситуация. Каждый такой фреймворк по своему уникален, так что "знание реакта" мало чем помогает при вхождении в проект.

    Polymer. JS. Попытка воспользоваться самыми последними стандартами. Всё крутится вокруг DOM, что весьма не эффективно. Реактивности как таковой нет. Спека ShadowDOM имеет уже вторую версию и та весьма ограниченна и требует костыльных костылей и вытягивания гланд через анус при использовании. Динамика с одной стороны отличная - рендерите что угодно куда угодно и динамически всё подгружается. Но без "вулканизации" вся эта динамика дико тупит, поэтому всё-равно всё объединяют в один бандл.

    $mol. TS. Полностью динамичен и ленив. Что угодно может быть динамически загружено, но в этом нет необходимости, так как компоненты получаются крайне компактными, а в бандл тянется лишь то, что реально используется. Рендерит тоже по возможности лениво, что позволяет быстро показать даже очень большую страницу. Имеет стандартную библиотеку компонент. В качестве примера, могу привести визуальный редактор компонент, который динамически строится по его коду и тут же в рантайме этот компонент изменяет (он ещё в разработке, но уже много чего позволяет): mol.js.org/#demo=mol_app_hello/edit/path

    К тем вариантам, что "JS", разумеется можно прикрутить сбоку и TS, но очень ограниченно:
    1. Будет много кода с декларациями типов и мало выведения типов.
    2. Практичная с точки зрения JS магия вырождается в весьма непрактичную борьбу с типизацией.
    3. Многие библиотеки/плагины/компоненты написаны на JS. В лучшем случае вы сможете своими силами написать для них типы.
    Итого:
    1. Под вашу задау идеально подходит $mol, но он далеко не в тренде (80 звёзд на гитхабе, ага). На нём можно быстро разрабатывать приложения, но сложно найти работу. Если есть желание, то мы ищем разработчиков от стажёров до сеньёров.
    2. Из востребованного сейчас на рынке: AngularJS, React*. Мой прогноз - скоро реакт выйдет из моды. Многие уже обожглись на нём, нафигачив горы говнокода, и переползают на более практичный Vue.
    3. Для устройства в Я имеет смысл изучать BEMJS (тогда точно возьмут :-D) или что-то трендовое типа React или Vue ну и VanillaJS нужно знать обязательно. Я сам в нём 2 раза работал, но как видите самореализоваться там не смог.
    4. Так как сроки у вас поджимают, то переписывать проект уже поздно. Так что лучше подумать о типичных костылях: CDN, нескучная анимация загрузки, агрессивное кеширование. Тем не менее по скорости разработки я бы отсортировал решения в следующем порядке (от быстрой к медленной): $mol, Vue, Angular, Polymer, React*
    5. Производительность и размер приложений на упомянутых фреймворках можете сравнить тут: mol.js.org/app/bench/#bench=https%3A%2F%2Feigenmet...
    6. Так как у вас энтерпрайз, то выбирать стоило бы из фреймворков, предоставляющих свою библиотеку высокоуровневых компонент (ExtJS,OpenUI5,KendoUI,VCL.JS,$mol). Энтерпрайзу обычно скорость разработки, богатство и единообразие функциональности важнее кастомных дизайнерских изысков на каждом экране.
    7. Для разработки более-менее крупных поектов имеет смысл брать фреймворки написанные с использованием статической типизации, тогда вы получите от типизации больше преимуществ и меньше боли. Их пока ещё не очень много: Angular (TS/Dart), $mol (TS), CycleJS (TS), VCL.JS (TS)...
    8. Джуниору лучше не заниматься созданием нового фреймвора (даже на Реакте), ничем хорошим это не закончится. Тут нужен опыт, чутьё и рациональность. Не у каждого сеньёра это всё есть.
    9. IE10 - это боль и страдания. Вы профилировали, на что именно уходит больше всего времени (загрузка, инициализация приложения, загрузка данных рендеринг)? Возможно стоит уменьшить объём единовременно отображаемых данных или подумать о серверном рендеринге ангуляровских шаблонов.
    Ответ написан
  • Дата и JS, как подружить?

    @vintage
    Ответ написан
    Комментировать
  • Как получить содержимое HTML комментариев через querySelector?

    @vintage
    Вам поможет XPath и document.evaluate.
    Ответ написан
    Комментировать
  • Как задать такую непрозрачность?

    Комментировать
  • Зачем в JS оборачивать именованную функцию в анонимную?

    @vintage
    Видимо не такая уж книжка и замечательная :-) Нет в этом никакого смысла.
    Ответ написан
  • Почему ломается ответ JSON меньше 10 строк?

    @vintage
    Первая ссылки не работает. Но подозреваю проблема в BOM.
    Ответ написан
  • HTML5 семантика: DIV в теге A?

    @vintage
    Раньше было нельзя. В html5 уже можно.
    Ответ написан
    Комментировать
  • Обясните как это работает в js?

    @vintage
    Начнём с того, что ваш код не работает :-) На это в общем и закончим.
    Ответ написан
    1 комментарий
  • Почему тулзы в windows не добавляют сами себя в PATH?

    @vintage
    Потому, что эти тулзы изначально разрабатывались не для windows, а авторы либо ленивые, либо "пользователи винды должны страдать", либо и то и другое. Нормальные тулзы сами всё прописывают.
    Ответ написан
    Комментировать
  • Какие возможности css препроцессоров вы используете?

    @vintage
    Предпочитаю не локиниться на какой-то препроцессор, который рано или поздно вымрет, а использовать лишь cssnext.
    Ответ написан
    Комментировать
  • На что переехать с knockout.js и стоит ли?

    @vintage
    Observables так или иначе будут везде. Так что поменяете шило на мыло.

    React вы не сможете адекватно встроить в уже готовый HTML.
    Angular превратит вашу простую задачу в звездолёт.
    Vue сможет встроиться в ваш HTML так же легко, как и Knockout. Там те же observables и computed, разве что вместо this.foo( val ) вы будете писать this.foo = val, а все computed нужно будет объявлять отдельно.

    Но если всё же соберётесь сделать SPA, то я бы рекомендовал наш велосипед: https://github.com/eigenmethod/mol
    Ответ написан
    3 комментария
  • Использование ngIf?

    @vintage
    А в самой статье не написано почему "лучше избегать использования ng-if и ngIf"?
    Ответ написан
    Комментировать
  • Создание элемента - какая схема лучше?

    @vintage
    Совсем идеальный вариант: клиент генерирует GUID и для него создаёт свою локальную запись. Далее сразу или по нажатию кнопки "сохранить", происходит синхронизация с сервером. Если на сервере нет записи с таким GUID, то она создаётся. Если есть, то проверяются права доступа и если всё ок, то изменения применяются.

    Чем это хорошо:
    1. Все запросы идемпотентные (их можно безопасно повторять при затыках сети).
    2. Даже у не сохранённой на сервере записи есть уникальный идентификатор, что сильно упрощает клиентскую логику.
    3. Не захламляется база данных временными записями.
    4. Логика работы клиента не зависит от протокола взаимодействия. Вам не нужно предварительно создавать запись, прежде чем её редактировать, не нужно иметь две различные логики работы для записей с локальными идентификаторами и с серверными. Просто создаёте записи и работаете с ними, а взаимодействие с сервером обеспечит отдельный заменяемый адаптер.
    5. GUID можно генерировать сразу человекопонятным. Например, для блога это может быть "vintage/2017-03-08T12:47:33". Обратите внимание, что тут мы не позволяем создавать более одного поста в секунду. Записи, созданные в одну и ту же секунду будут одной и той же записью.
    6. Вы сами решаете когда и как сохранять данные на сервер и это не навязывается вам протоколом.
    7. На запись, которая ещё не сохранена, уже можно дать ссылку. Фактически создана она будет лишь после первого редактирования. Актуально для вики проектов, где вы сначала создаёте ссылку, потом по ней переходите, и только тогда уже заполняете.

    Чем это плохо:
    1. сквозная нумерация не представляется возможной. Но она и редко когда необходима.
    2. Идентификаторы получаются относительно длинными. С другой - они могут содержать некоторую метаинформацию. Например - когда, кем и где создана.
    3. В базе для GUID должна быть дополнительная текстовая колонка с уникальным индексом. Но скорее всего всё-равно у вас такая будет, когда начнёте внедрять [slug](https://ru.wikipedia.org/wiki/Семантический_URL#Slug) для человекопонятности.
    Ответ написан
    Комментировать
  • При подобном подходе всегда использовать bind?

    @vintage
    Используйте стрелочные функции:

    router.get('/', ( ...args )=> index.mainPage( ...args ) );
    Ответ написан
    Комментировать
  • Почему Angular 2 + TypeScript очень долго собирается webpack?

    @vintage
    Отключите минимизацию-оптимизацию и всё ускорится.
    Ответ написан