Ну, уж не пол офиса.
Все правильно, чтобы выбрать себе коллегу, который может и будет ошибаться первые пол года, но потом втянется и станет знать, где какие сервисы, какие ограничения.
И эти пол года тебе должно быть комфортно с ним работать
Ну не пугайте уж.
Суммарно на получение ипотеки ушло 21к евро, из которых 16 — налог на передачу имущества(те самые 2%).
Оценщик — 500 евро, 2КЕ — эвдайзер ипотечный и еще тысяча на нотариуса и прочее.
Вот вы привели пример:
onChange={e => callExpression}
setName — параметр из props, мы изначально можем сказать, что это функция — Output.
Проброс — так же весьма интересный вариант. Дело в том, что проброс — это не вызов :) А значит — инпут :)
А вот это куда более интересно.
Output не используется в рендере, грубо говоря, он ничего не возвращает.
Более того, мы знаем, что самое частое использование аутпута —
this.props.*(someData?)
Т.е., это функция, результат которой не используется в JSXExpressionContainer'е как таковом(не является чайлдом)
Именно поэтому я и написал про статический анализатор предметов, чтобы в процессе написания нового видеть возможные пересечения. В конце-концов всегда можно переопределить другой или написать более специфичный предикат
Так почему лимитировать? Предикаты как раз и служат для того, чтобы расширять(до тех пор, пока не начнутся пересечения, на крайний случай, можно модифицировать набор входных паттернов).
Т.е. если у вас вдруг появилась конструкция, которая ранее не встречалась — новый предикат и генератор, проблема решена.
Это вы сейчас про JSX -> Angular Template?
Так вот, операции над входными параметрами, которые проводились в JSX будут переведены в TS.
Так, например, мутации перед итерации с массивом элементов — изначально выдернуты и не отображаются в результируюзем html-шаблоне. Эти операции будут вынесены отдельно в TS.
Над этим я прямо сейчас работаю
А еще при оценке пользоваться планнинг покером, с целью максимально быстро оценить затраты на выполнение задач всей командой, нежели ориентироваться на «Я выполню задачу за 5 часов», и накидывать еще 20% потому что «это не точно»
При использовании ES2015 стоит использовать let вместо var.
Да и при построении React компонентов, лучше описывать типы параметров, передающихся в компонент, ведь читаем мы код чаще, чем пишем ;)
Это исключительно различие в менталитете, культуре.
Это как если бы вы сказали, «зачем вы держите русских в компании и приносят ли они пользу?»
Ну, уж не пол офиса.
Все правильно, чтобы выбрать себе коллегу, который может и будет ошибаться первые пол года, но потом втянется и станет знать, где какие сервисы, какие ограничения.
И эти пол года тебе должно быть комфортно с ним работать
Суммарно на получение ипотеки ушло 21к евро, из которых 16 — налог на передачу имущества(те самые 2%).
Оценщик — 500 евро, 2КЕ — эвдайзер ипотечный и еще тысяча на нотариуса и прочее.
Это не решает проблемы. Нативность лучше, чем тащить кучу зависимостей
Новый рендер не отменяет того, что сами архитектуры кардинально отличаются, и существенной разницы не будет
onChange={e => callExpression}
setName — параметр из props, мы изначально можем сказать, что это функция — Output.
Проброс — так же весьма интересный вариант. Дело в том, что проброс — это не вызов :) А значит — инпут :)
Output не используется в рендере, грубо говоря, он ничего не возвращает.
Более того, мы знаем, что самое частое использование аутпута —
this.props.*(someData?)
Т.е., это функция, результат которой не используется в JSXExpressionContainer'е как таковом(не является чайлдом)
Именно поэтому я и написал про статический анализатор предметов, чтобы в процессе написания нового видеть возможные пересечения. В конце-концов всегда можно переопределить другой или написать более специфичный предикат
Можно же определить генератор для определенного HOC'а.
Вы не ограничены ничем :)
Т.е. если у вас вдруг появилась конструкция, которая ранее не встречалась — новый предикат и генератор, проблема решена.
Про ключи — да, я выдергиваю это, в целом, trackByFn — это ReturnStatement с содержимым аттрибута key.
Конечно же мультиразовая :)
Возможно, конвертировать HOC'и в сервисы.
Посмотрим
Так вот, операции над входными параметрами, которые проводились в JSX будут переведены в TS.
Так, например, мутации перед итерации с массивом элементов — изначально выдернуты и не отображаются в результируюзем html-шаблоне. Эти операции будут вынесены отдельно в TS.
Над этим я прямо сейчас работаю
В данном случае, при рендере объекта переменной this.filterTextInput будет присвоен этот ReactElement
Да и при построении React компонентов, лучше описывать типы параметров, передающихся в компонент, ведь читаем мы код чаще, чем пишем ;)