- 1
- 2
- 3
- 4
- 5
- 6
- 7
public do(action: 'un' | 're'): void {
const result = (<any>this._appApi.app.documentManager.current)[action + 'do']();
if (!result.success) this._toastService.error(result.errorMessage, `Ошибка ${action}do`);
}
<button (click)="do('un')" title="Отменить"><i class="material-icons md-36">undo</i></button>
<button (click)="do('re')" title="Повторить"><i class="material-icons md-36">redo</i></button>
mazhuravlev, это такой ECMAScript стал в 2017?
Как они прикручивают статическую типизацию ко всякой хрени типа jquery?
Со сторонними библиотеками несколько путей: могут уже существовать определения типов для популярной библиотеки, здесь например: https://www.npmjs.com/~types, можно написать определения самостоятельно, и еще есть вариант просто задекларировать переменную, в которой лежит библиотека, если она подключается глобально, как any, это так сказать выход в js, у any него не проверятся ничего. Пишем declare let jquery: any; и делаем с ним, что хотим.
красивое решение
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/jquery/index.d.ts
Если ещё можно дописывать свои сигнатуры или изменять старые (на случай, если типы отстали от библиотеки), то всё вообще хорошо.
Но выбора-то нет: хочешь стат типизации -- пиши скелетики
Я понимаю что TS лучше чем JS, понимаю что статическая типизация и WebStorm сильно упрощают программирование (с js webstorm почти не помогает)
Это всё же лучше, чем мне писать и .c, и .h. Мне бы пришлось постоянно следить не только за скелетиками, но и за логикой - либо копировать куски кода при каждом обновлении библиотеки (реализация в библиотеках меняется чаще, чем интерфейсы), либо всё это реализовывать самому с нуля.
Хоть какое-то переиспользование.
Ну, обычно это делает IDE:) Писатели на С, C++ и ObjectiveC так именно и живут.
Компилятор найдет.
> рефакторинги
Search&replace порефакторит.
> генерацию бойлерплейта
Расслабляет и дает голове отдохнуть.
> Расслабляет
Больной ублюдок!
Особенно это удобно когда тебе надо посмотреть "кто еще использует метод".
>>Search&replace порефакторит.
Особенно метод с именем getName()
>>Расслабляет и дает голове отдохнуть.
Лучше сделать зарядку.
На самом деле с IDE есть одна проблема: она упрощает написание ГОВНА.
Когда ты пишешь в редакторе (да еще и на скриптовом япе, лол!) ты просто вынужден держать в башке примерную архитектуру и писать внятную доку тоже должен.
А когда у тебя есть IDE то начинается "ой, я не знаю как это работает, поищи использования и сделай аналогично, посмотри по коду, подебажь, итд"
> Особенно метод с именем getName()
Просмотр каждого изменения решит этот вопрос. Сначала поиск и замена по одному вхождению, чтобы убедиться, что в этом месте действительно нужна была замены; потом повторный поиск и просмотр всех вхождений, чтобы убедиться, что (а) заменено всё, что надо (б) заменено как надо.
Например, у аргумента функции f сменился тип. В некоторых местах надо заменить f(x) на f(T'(x)), а в некоторых - оставить как есть, т.к. в функцию, вызвавшую f уже передали новый T' вместо старого T. Компилятору оставлять такое не стоит - мало ли, какие там неявные касты могут быть (преобразования между 6 типами в JS и практически бесконечностью типов в C++)
Рефакторить - так рефакторить, а не просто имена менять.
Не вижу смысла ходить в 28 мест и везде менять A и A'.
Если ЯП стат типизирован то компьютер может решить эту задачу, а раз может -- пусть решает.
Но это относится только к стат типизации конечно. В твоем JavaScript все равно придется проверить руками все места (ну или положиться на покрытие тестами) и потому для JS IDE нужен куда в меньшей степени. А может и вообще не нужен
Компилятор имеет возможность в идеальном случае, да.
Но я же говорю, неявные касты портят картину.
К тому же, пройти прокликать все ошибки и поискать все вызовы f - занятие почти эквивалентное. К тому же, если запустить компилятор до того, как некоторые функции, вызывающие f, перевели на T', он укажет на эти места, но менять там ничего не надо.
> для JS IDE нужен куда в меньшей степени. А может и вообще не нужен
Как минимум, питушня, подсказывающая имена сущностей, здесь полезна.
Ну всё таки в 80% он поможет и сэкономит время.
JS просто трудно обычно статически хоть как-то анализировать, и потому WebStorm показывает все, известные ему символы:)
Всё так. Жаль только, что уйдёт это время на отладку какой-нибудь нехорошей питушни. Всё тлен.
По сравнению с текстовым редактором, который за то же время успевает открыться, открыть пачку открытых в прошлой сессии файлов, подсветить весь синтаксис и отзывчиво ждать пользовательского ввода, это ад.
Текстовый редактор делает практически всё то же самое, только позволяет экономить время пользователя, ресурсы ПК. И вентилятором не шумит.
>>Текстовый редактор делает практически всё то же самое
Ну это же не правда. VS с R# делают
1) код комплишен
2) рефакторинги
3) инспекции (это правда помогает отлавливать оишбки, особенно в сях)
4) реформат кода и удаление ненужных импортов
5) нафигацию (контрол клик на имени)
6) подсветку упавших в CI тестов
Да много чего
зы: Но я знаю что есть люди, которые не юзают Intellij, VS и Eclipse ровно потому что он грузится у них три минуты.
Ксатти, у VS есть VS Code: этопросто редактор
Такое ощущение, что делают они всё это одновременно для всех файлов на моём ПК, и ещё в интернеты лезут докачивать исходники, с которыми тоже надо поработать.
Как с бесплатной медициной и т.п.: ты этим можешь не пользоваться, но налоги платить будешь. Ты не жмёшь "рефакторинг" или "реформат", а IDE всё равно внутри что-то считает и греет процессор в надежде выдать закэшированный результат за 0.01мс, когда ты наконец нажмёшь на кнопку. IDE умудряется тормозить даже в тех местах, где просто невозможно тормозить.
> Ну это же не правда
Правда. По крайней мере, notepad++ делает быстрее IDE то, что делает notepad++.
К счастью, у тебя есть выбор.:)
Смотришь на размер студии с отключёнными в установщике галочками и осознаёшь, что будущее наступило. Копируешь Eclipse, а там тысячи каких-то файлов медленно плетутся из папки в папку.
Оставить бы, скажем, 100МБ на диске, менюшку из меньшего количества пунктов, панельку только одну и фичи только те, которые нужны.
А то предлагают либо велосипед купить, либо самосвал.
>>Попробуй Qt Creator.
для JavaScript/
QML - тот же экмаскрипт. Так что как минимум подсветка там есть. Х.з. как с отладкой, автодополнением и рефакторингом, я особо с QML не работал.
Emacs это редактор или IDE?
> Emacs
Не видел, не знаю. Когда я говорю об иде, я имею в виду программы типа вижуалстудии или эклипса или кутэкреатора.
Хотя сам факт наличия таких проектов весьма не однозначен, да
Может быть IDE это как дезодорант, который заглушает запах проекта (Фаулер так говорил про комменты)
Emacs — это интерпретатор elisp, ориентированный на работу с текстом. Может быть чем угодно.
> принудительного вывода названий аргументов
Не знаю, что это.
вот так чтоль?