[ts] Property 'value' does not exist on type 'EventTarget'.

так получше, т.е вернулся откуда начал

У тебя там какой тип события?

ChangeEvent?

ага onChange

public valueChange = (e: React.ChangeEvent<HTMLInputElement>): void => { }

public valueChange = (e: React.ChangeEvent<HTMLInputElement>): void => { }

помогло, чет башка не варит сейчас, очевидно же было( спс.

Забавно что tsc ошибки гонит в stdout

приходится по слову error подсвечивать

а тут есть Евгений?

приходится по слову error подсвечивать

А в чем проблема из stdout брать?

Он ж больше ничего и не пишет

не проблем. кроме огорода

gulp.task('tsc', function (cb) { var firstCompilation = true; // typescript watch is the best one var tsc = spawn(require.resolve('./node_modules/.bin/tsc'), ['--module', 'amd', '--target', 'ES5', '--jsx', 'react', '--sourceMap', '--outDir', './public/js', '-w', './src/index.tsx']); tsc.stdout.on('data', (data) => { var dataStr = data.toString(); if (dataStr.toLowerCase().indexOf('error') === -1) { gutil.log('[tsc] ' + dataStr); } else { // tsc otput errors to stdout! gutil.log(gutil.colors.red('[tsc:error] '+ dataStr)); } if (firstCompilation) { firstCompilation = false; cb(); } else { if (tscCompilationCompleteRegex.test(dataStr)) { browserReload(); } } });

Так а что там кроме ошибок может быть?

var tscCompilationCompleteRegex = / Compilation complete\. Watching for file changes\./;

надо же браузер перегрузить если все ок

еще [22:23:28] [tsc] 10:23:28 PM - File change detected. Starting incremental compilation...

в общем вот собрал сегодня ts->amd, с реактом, который через systemjs грузит приложение. В отличие от вебпака реквайр пофайловый. Как в старом добром requireJs

https://github.com/olegsmetanin/typescript-systemjs

я бы dynamic import ждал)

Самое лучше этт partial классы... это бы было замечательно

Самое лучше этт partial классы... это бы было замечательно

сомнительно

Когда компонент растет а размере и даже декларвция переменных занимает много место syntax sugar который приносят partial улучшит readability и scalability я не говорю о части класса который может быть автоматически генерируемый... это очень классная вещь

Композиция, не?

Если компонент растет, его надо разбить на мелкие компоненты

Не всегда применимо и communication может привести к ненужной сложности ... часто это может быть приметивная логика но в большом количестве типа много однотипных контроллов на экране.. но они могут быть с позиции бизнесса единым целым и разбивать их на отделтные компоненты не имеет смысла

В этом случае partial идеалтно работает

Только что обсудили смысл — удобство поддержки

С позиции бизнеса это всё — просто препятствия на пути к продукту)) Как будет удобнее с точки зрения разработк — так и лучше

???? типичный технический вгляд... помни who pays ur salary mate )))...это мне сказали много лет назад один человек я как и ты подумал.. но с годами я понял у меня зп была ну пусть 100 ка в год у него было состояние 20 млн баксов

Если ты пишешь для себя то да а так ты пишешь потому что есть бизнесс

Не ьудет не будет и програм

Слабо представляю, когда с точки зрения бизнеса не получается разбить компонент

@mkusher воооо. щас я тебя буду мучить вопросами

расскажи мне, как организовать минимальное окружение, чтобы писать на тайпскрипте и гонять tdd/bdd тесты?

jasmine-ts это правильный выбор?

jasmine-ts это правильный выбор?

Я моку юзаю

mocha+chai+sinon

что у меня должно быть в package.json?

чтобы вот прям самый минимум

тесты в консоли

у меня была ситуация когда консалтент написал джененрик компонент и стал испльзовать его в двух с точки зрения бизнесса разных компонентов так вот требования росли и компоненты удалялись друг от друга когда настал момент и он сказал что все не может это быть дженерик и надо их разбивать и потребуется спринт на это))) вот это было issue потому что с позиции бизнесса они были всегда разные) на синиро уровне когда общаешься с бизнесс репресентативс важныую роль играет alignment с бизнессом и понимаешь стратегии компании) ну это так если кто то хочет больше чем быть инженером)

mocha+chai+sinon

Истанбул ещё не научился сам ремапить?

npm i -D mocha chai sinon sinon-chai @types/mocha @types/sinon @types/chai @types/sinon-chai

Истанбул ещё не научился сам ремапить?

nyc

Он норм мапит

у меня была ситуация когда консалтент написал джененрик компонент и стал испльзовать его в двух с точки зрения бизнесса разных компонентов так вот требования росли и компоненты удалялись друг от друга когда настал момент и он сказал что все не может это быть дженерик и надо их разбивать и потребуется спринт на это))) вот это было issue потому что с позиции бизнесса они были всегда разные) на синиро уровне когда общаешься с бизнесс репресентативс важныую роль играет alignment с бизнессом и понимаешь стратегии компании) ну это так если кто то хочет больше чем быть инженером)

При добавлении ответственности можно было раньше увидеть, что компонент начинает делать слишком много

dry он конечно про business value, но тут мы сами должны танцевать, чтобы на длинном отрезке получить профит

dry он конечно про business value, но тут мы сами должны танцевать, чтобы на длинном отрезке получить профит

чсх, сейчас, в тех местах, где нет какой-то очень ясной модели разбиения на классы, ответственности и прочую ерунду, код пишется по принципу "ебашь вперёд". И, что самое удивительное, страданий по этому поводу еще никто не испытал.

Я сейчас не про top level архитектуру, а про внутреннюю кухню.

Просто в определенный момент, наступает понимание, что вот эту портянку и 2к loc надо разобрать на части, потому что вот теперь-то понятно, как это должно работать.

Да, рефакторинг это часть процесса, а не какой-то этап, который надо выпросить)

И очень часто то понимание, которое есть в начале, о том как это разбить на части, и как части будут друг с другом взаимодействовать, очень сильно отличается от того, что происходит после того, как код уже battle tested

Good enough и все такое

Такие дела. Ага

npm i -D mocha chai sinon sinon-chai @types/mocha @types/sinon @types/chai @types/sinon-chai

помоги мне, пожалуйста, это все запустить теперь. Вот, например, сделал я src/hello.ts, написал src/hello.spec.ts. куда теперь копать?

помоги мне, пожалуйста, это все запустить теперь. Вот, например, сделал я src/hello.ts, написал src/hello.spec.ts. куда теперь копать?

Браузерное что-то или серверное?

будет браузерное. но я пока хочу просто с языком поиграться

ERROR: S client not available

погонять тесты в консоли

без DOM

Короч самый простой вариант - в tsconfig указать outDir: lib

так

указал

Добавь в package.json в scripts: start: tsc -w specs: mocha lib/hello.spec.js

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

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

Как отсюда следует, что компоненты надо делать большими и не бить на более маленькие?)

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

partial решили бы это в секунду) поэтму классно было бы если бы это добавили

тем более я говорил о примитивно куче однотианый скажем компонентов типа rich text area)

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

Очевидно ему неинтересно, более того, если они начали интересоваться, то вероятно я плохо работаю, что даже бизнес вкурсе

нет просто если завтра ты бы не успел то не было бы ни тебя ни их)

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

это, кажется, называется управление техническим долгом

вот это бизнесс волнует)

это, кажется, называется управление техническим долгом

+

backlog)))))

это другое

это management control

и тип контороля

скажем в критический ситуации лучший будет micromanagement

Стойкое ощущение, что читаю натянутое обоснование для любимой фичи

Которую даже в C# завозили по вполне конкретной специфичной причине

Никакого отношения к бизнесу с громадными компонентами не имеющего

Проблема в том, что в js достаточно гибкости, чтобы реализовать и такую фичу Просто это никому совершенно не нужно

в том же си шарпе партиал играет огромную роль в автогенериремом коде например с теми же ORM типа EF тоже самое бы дало окромный буст джава скрипту) мне честно наплевать на эту вищу я вообще честно в комерческом аспекте давно отошел от программинга)

а если быть честным то подобный реквест был сделан пару лет назад но видимо решили что мало кому нужно)

у меня была ситуация когда консалтент написал джененрик компонент и стал испльзовать его в двух с точки зрения бизнесса разных компонентов так вот требования росли и компоненты удалялись друг от друга когда настал момент и он сказал что все не может это быть дженерик и надо их разбивать и потребуется спринт на это))) вот это было issue потому что с позиции бизнесса они были всегда разные) на синиро уровне когда общаешься с бизнесс репресентативс важныую роль играет alignment с бизнессом и понимаешь стратегии компании) ну это так если кто то хочет больше чем быть инженером)

я раньше искренне не понимал людей, которые хаят использование иностранных слов в речи, но читать такое становится действительно отвратительно)) без обид