JSX: антипаттерн или нет?

Кроме этого имя функций должно быть минифицировано при сжатии JS.

JSX: антипаттерн или нет?

У меня изначально было name, когда еще функции использовал вместо классов, но function.name не все браузеры понимали, перешел на $name.

JSX: антипаттерн или нет?

Глупости. Я не сторонник наличия в команде чистых верстальщиков, мне удобнее когда в команде работают более хардкорные люди. Но все таки чистые верстальщики еще не вымерли, и в моем понимании это html + css + less/sass.

JSX: антипаттерн или нет?

Кстати помимо теологических причин держать разметку и код в одном файле неудобно даже с точки зрения мержа. То есть когда эти вещи разнесены по разным файлам вероятность конфликтов при мерже меньшая. И уж тем более мне не хотелось бы чтобы верстальщики (чистые верстальщики) лазили в код компонентов и что-то там меняли.

JSX: антипаттерн или нет?

У меня в коде вообще реакта нет — это модуль-класс для регистрации кастомного элемента авторизации

Я вот и интересовался как потом этот инлайн обработчик отключается.

JSX: антипаттерн или нет?

Очевидно придется поработать с DOM напрямую.

А React автоматически отключает подобные инлайн листенеры когда элемент уже не используется?

Я правильно понимаю что React использует even delegation подоход? То есть зарегистрированный явным образом листенер (addEventListener) не добавится к указанному элементу, а просто зарегистрируется как обработчик в одном глобальном листенере топ уровня (на основе генерируемого id компонента или что-то вроде этого)?

JSX: антипаттерн или нет?

В результате сложно найти все места, которые ссылаются на определенную зависимость. Второе, зависимости указываются по строковым именам, что неудобно.

Не идеально, но удобнее чем некоторые используют первый ангуляр (особенно не люблю указывать зависимости по строковым именам).

@Component({
    __filename,
    bindings: {_input: '< input'}
})
class Controller extends require('./../common/base-class') {
    static $inject = [
        require('./../common/crud-service').$name,
        require('./hr-expert-data-service').$name,
        '$scope',
        '$q'
    ];

    constructor(Crud, expertDataService, $scope, $q) {
        super({Crud, expertDataService, $scope, $q});
    }

@Component — самописная обертка в стиле второго ангуляра. $name во все сущности ангуляровские подставляется на основе имени файла автоматически (по переданному значению __filename). В базовом конструкторе {Crud, expertDataService, $scope, $q} (зависимости) линкуются в отдельное поле объекта.

JSX: антипаттерн или нет?

От ES6 шаблонов это отличается несколькими дополнительными кавычками и ${form} вместо { form }, JSX в этом случае выглядит как оверхед.

JSX: антипаттерн или нет?

> Нормальная работа с новыми возможностями джаваскрипта, в частности с модульностью. Ангуляр 1 бесит в этом плане, хотя без модульности он радовал.

Что не так с модульностью в Ангуляр 1 (и причем зедсь вообще Ангуляр 1, модульность это базовая/абстрактная вещь)?

Пособие по webpack

Я ведь то же самое выше написал :) grunt/gulp раннеры, по сути голый JS облагороженные некоторой не слишком жесткой структурой, поэтому очевидно свобода полная, а webpack декларативная вещь. Это как например сравнить Ant c Maven в Java мире, при этом их тоже можно использовать вместе.

Пособие по webpack

grunt и gulp могут быть полностью заменены webpack-ом только в том случае, если их задачами была только сборка проекта.

Пару примеров где webpack не справится учитывая написание кастомных плагинов/лоадеров? В целом конечно же grunt и gulp это раннеры задач. считай скрипты, что х-очешь то и делай, а webpack гораздо более деакларативная вещь которая свою задачу выполняет лучше простых скриптов тк она специализирована. Никто не мешает использовать webpack в связке с gulp при необходимости, это не взаимоисключающие вещи. В большинстве случаев webpack заменяет собой gulp/grunt.

Пособие по webpack

— как настраивать различные окружения (например, dev для локального запуска, а prod с минификацией и ссылками на реальные бэкенды);

Элементарно, на основе переданных переменных окружения, у вас ведь вся инфраструктура Node.js в руках. В деталях реализация может быть разной, например используя webpam-merge модуль, ограничений нет.

— как собирать готовый билд, который потом можно выкатывать в продукцию (не просто js-бандл, а отдельная директория / zip / jar со всем необходимым);

Как вам более удобно так и собирать, у меня допустим Maven билдит Java и вместе с этим весь фронт, включая и Webpack и Gulp и прочий зоопарк.

— как интегрировать всё это с процессами бэкенда (аля, написал «gradlew build» и на выходе получил и фронт и бэк).

Как вам более удобно так и интегрировать. Webpack — винтик в общем стеке и нет проблем его интегрировать куда-либо.

10 особенностей Webpack

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

10 особенностей Webpack

Еще «resolve.alias» очень полезная вещь.

10 особенностей Webpack

Новички не знают, но указывая entry таким образом (путь как имя entry) можно иметь разные output для разных entry, иногда бывает очень полезно:

entry: {
    '/modules/someModule': './src/modules/someModule')
}

На выходе получите бандл помещенный в /modules/someModule относительно output.path.

Как уже указывали выше, если работаешь с Webpack плотно, делая не совсем типичные вещи, придется читать исходиники, документация не полная.

10 особенностей Webpack

как если бы его три раза вызвали с разными конфигами.

а почему «как если бы» если это так и есть

Почему компании так упорно хотят иметь Fullstack разработчиков?

Кстати это в Германии такой рынок?

Почему компании так упорно хотят иметь Fullstack разработчиков?

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

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

Почему компании так упорно хотят иметь Fullstack разработчиков?

Речь ведь была о том чтобы запилить фичу, разумеется стратегические решения в одиночку не принимаются, хотя зависит от состава команды (иногда просто никто не хочет или не способен учавствовать в процесс принятий решений кроме одного-двух человек). Смысл фуллстека в моем понимании проявляется когда нужно сделать что-то быстро и без особого ущерба качеству, такое нужно не всегда если конечно это допустим не конвеерная разработка прототипов. Также в целом приятнее общаться с фуллстеком видя что он или уже знает о чем идет речь или схватывает все на лету, общая техническая эрудиция на высоком уровне.

PS предоплагает что когда фуллстек берется сделать что-то «быстро» и относительно качественно, то все вопросы (очень общие вопросы) указанные выше уже решены, дело перешло к конкретике.

Почему компании так упорно хотят иметь Fullstack разработчиков?

Вы не поняли смысла, фуллстек товарищ способен и задает все нужные вопросы самостоятельно, не отвлекая узких специалистов, и обычно досточно задачть все вопросы на начальном этапе разработки фичи. Кроме этого в процессе выполнения он не отвлекает узких специалстов вопросами вида «а где там и как и откуда, какой там формат API и тд», а просто делает результат. Но если честно это не значит что фуллстек всегда будет так действовать (некоторые все же предпочитают фокусировать в бэкенде или фронте, ресерче, тимлидстве и тд), но в момент необходимости его навыки и способности могут быть очень полезны для команда/компании.