k12th
0

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


Я сделал недавно текстовую игру в порядке эксперимента, где действия обозначались эмодзи вместо слов. И все было прекрасно на Win10 Pro, пока я не открыл ее на мобильнике, где вместо половины картинок были квадратики. Списав на старую версию (4.4), я пошел на работу и открыл на Win10 Enterprise, где ситуация оказалось не сильно лучше. Пришлось искать специальный шрифт, который весит на полтора порядка самой игры, и делать отдельную версию, потому что нельзя же всех заставлять качать 6 мегов для текстовой-то игры.


В общем, если вы спросите меня: «готова ли инфраструктура для всемирного перехода на эсперанто колобков и какашек?», мой твердый и решительный ответ будет: «может быть, подождите пока».

k12th
0

Окей, я понял, спасибо. По прежнему не согласен (стримов нет; а отбрасывать-то можно что угодно, но ведь (state) => state они редьюсером не называют), хотя бы корни терминологии ясны.


А стримы, наверное, возникают, когда делаешь time-travel: берешь initial state и проходишь по массиву случившихся экшенов, чтобы получить состояние в желаемой точке.

k12th
0

Так нет никакого «вместо», под капотом это так и работает.


Как я уже и сказал, можно спокойно управлять стейтом без vuex и ФП.

k12th
0

Не буду делать вид, что понял, зачем экшены живут в списке, и в чем тут сходство сигнатуры, когда редьюсеры в JS имеют вид (accumulator, currentValue, index, array) => value, но за объяснение спасибо.

k12th
+1

Для этого vuex не нужен, скармливаете любой объект vue.js, она сама будет следить за свойствами. Вместо геттеров — computed (и watch), вместо экшнов — methods.


vuex, в некоторой степени, дань моде на ФП подход в UI; в отличие от React тут действительно есть реактивность и UI перерисовывается без создания нового объекта.

k12th
+1

Не знаю начет Redux + reselect, но похоже на MobX. Иммутабельности нет, vue наоборот не любит, когда вы заменяете объект целиком.


С мемоизацией сложный вопрос. С одной стороны в явном виде ее нету. С другой стороны, при использовании геттеров ожидаемым образом — то есть в качестве computed-свойств в компонентах — vue сама следит, какие computed-свойства пересчитать, то есть какие геттеры вызвать.

k12th
0

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


Плюс есть т.н. «модули», когда вся бизнес-логика, относящаяся к некоторой части состояния, выносится и группируется отдельно.

k12th
+1

Если честно, я плаваю в redux-терминологии. Для меня редьюсер не выглядит так, будто он принимает очередь, а выглядит так, будто принимает стейт и возвращает объект, замещающий какую-то часть в стейте.

k12th
+2

А какой смысл называть mutation reducer'ом?

k12th
+2

Для всякого CRUD типа админок, да и просто быстро набросать основу — очень прикольно. Давайте продолжение!

k12th
+10

Неправда ваша, все знают, что в СССР было всё — и баги в том числе. Но с этими пережитками буржуазного прошлого боролись, перевоспитывали их в фичи.

k12th
0

Я бы всем этим манагерам и заказчикам посоветовал был офигенно действенную методологию под названием "пишем, бл***, код".


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

k12th
0

Ну предположим, но основная часть времени тратится все равно на (транc|ком)пиляцию, а из перечисленных вами языков имплементация на C есть разве только у SASS и еще может у MD.
А если они свои компиляторы TS и ES2015 написали на C, то я к этому не притрагивался бы палкой даже бесконечной длины.


Я щас посмотрел, оно еще и платное, о божечки:D

k12th
+1

Хороший GUI это хорошо, но в данном случае это примерно так же удобно, как рисовать картинки в CLI.

k12th
+3

Если label не содержит в себе input, то он и не будет работать как лейбл. То есть, нужен id у инпута и for у этого лейбла. И если верстка не совсем кривая, то найти нужный лейбл можно через $('label[for=" + this.id + '"]').

k12th
0

То ли дело плитки Пенроуза, да?

k12th
+2

Неплохая статья (и вообще весь сайт, побольше бы там материалов), но я лично, когда реализовывал гексовое поле, использовал как шпаргалку вот это: http://ondras.github.io/rot.js/manual/#hex/indexing

k12th
–1

Поясню: поскольку тип, структура и обязательность аргументов и возвращаемого значения теперь видна из подсказки интеллисенса, в исходники надо лезть только когда нужны какие-то тонкости внутреннего устройства.

k12th
0

Ну понятно, просто хотелось бы из коробки и нативненько.

k12th
0

Мне кажется, что если бы либу для управления состоянием написать на TS изначально, с расчетом на него и его систему типов, можно было бы сделать все это изящнее и лаконичнее.

k12th
–1

Спасибо за развернутый ответ.


В моем текущем проекте (его начинали еще на 1.8) у нас вместо enum тонна констант типа const ACTION_TYPE_BAR: ACTION_TYPE_BAR = "ACTION_TYPE_BAR"; и естественно хочется выколоть себе глаза.


Что до документации, то признаюсь, jsdoc-ом какое-то время не пользовался и даже не знал, что там все так грустно. А вот это чем сгенерено, typedoc (я там честно копался, но как дока генерится, не нашел)?

k12th
–1

Это правда, есть такая проблема. Но в таком кейсе и меньше необходимость копаться в чужих исходниках.

k12th
–3
Что-то тут наркоманией запахло

Переходите на личности?


а люблю ванильный js с jsdoc-валидацией

Значит, вас двое, потому что пока что я видел только усиленную пропаганду flow. «Шизофренией запахло», выражаясь вашим языком.

k12th
–2

А какая критическая разница между кодогенерацией и «выкусыванием»? И то и другое превращает код на одном языке в другой, и то и другое требует процессинга перед подачей в браузер/nodejs.


Вы можете сколько угодно себя убеждать, что flow лучше, но, как и в случае с jsx, это фейсбучное фанбойство субъективно.

k12th
–1

Действительно, откуда тут jsx...

k12th
–1
чистый js с типами в коде

Ага, и JSX не новый язык.

k12th
0
Согласен, однако, введение discriminated unions и свитчей по их ключам серьезно облегчает работу с пэйлоадами экшенов (из-за type narrowing), и это перевешивает весь необходимый бойлерплейт.

Покажите? Я общем-то новичок в обоих технологиях и не очень представляю, что вы предлагаете.


Ну это все за пару секунд затыкается простой наколенной .d.ts-кой, предназаченной как раз для таких затычек.

За пару секунд? Ну зависит от сложности библиотеки, конечно...


Гораздо лучше всяких esdoc/jsdoc/documentationjs и прочего

Чем оно лучше «гораздо»? Как по мне, так у jsdoc не хуже выходит — типы указаны, ссылки проставлены, комментарий написан, что еще надо? Остальное не пробовал.

k12th
+1

К сожалению, в реальном мире не все так безоблачно. Например, для Redux надо писать много бойлерплейта, и с TS его становится только больше. Не у всех пакетов есть качественные тайпинги (потратил два дня, чтобы компилятор перестал ругаться на adal-angular (ну да эта либа отдельная песня)). tree-shaking для TS пока что вроде бы нет. Language server иногда чудит, например, в WebStorm и VS Code ругается на кучу ошибок в проекте, причем на разные, и такое ощущение, что игнорит половину tsconfig.json — а проект при этом успешно собирается.


Но есть и плюсы, конечно. *.tsx это невероятно удобно, если не лениться описывать пропсы, и даже почти примиряет меня с React-ом. Изучать новые библиотеки, написанные на TS или с хорошими тайпингами, гораздо проще.


Еще я обнаружил, что WebStorm подхватывает определения из *.d.ts, даже если весь проект на JS — достаточно упомянуть нужный тип в jsdoc, и интеллисенс сразу умнеет. Можно начать свой путь в TS с этого, немного облегчить себе жизнь на отдельно взятом проекте, потратив пару часов и описав хотя бы самые важные типы. То же касается и сторонних тайпингов, установленных через npm install @types/lodash --save-dev. VS Code, ЕМНИП, вообще ставит тайпинги автоматически в фоне прозрачно (куда-то в свою папку, не в проект).

k12th
0

Разметку, состоящую из одних дивов и спанов, читать очень трудно. Есть даже шуточный диагноз «дивитоз». Как лингвисту, вам должно быть понятно, почему мы пишем на HTML/CSS/JS, а не на ассемблере.

k12th
0

По-моему, самое ценное изменение — появление человекочитаемой документации:) И даже конфиг стал чуть понятнее (хотя еще есть куда расти).

k12th
0
будто они совсем не заинтересованы в успехе проекта
k12th
+1

JS был разработан за 10 дней одним человеком, в нем есть и неудачные моменты, и это нормально.


На данный момент консенсус такой, что расширять прототипы кастомными методами считается плохой практикой. Судьба Prototype.js о чем-то да говорит.


Другое дело полифиллы, потому что они future proof.

k12th
+2

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

k12th
0

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

k12th
+3

Я не об этом. Про порог вхождения тоже можно поспорить — все-таки наличие многократно вычитанной документации и Q&A снимает множество вопросов.

k12th
+1

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

k12th
+3

Я не очень понимаю, при чем тут Webpack. Webpack !== babel, хотя они и используются часто вместе, но это не единственный вариант использования их обоих.


babel-node утилита командной строки, которая эмулирует поведение nodejs, только перед исполнением файла она его транспилирует и только потом передает настоящему nodejs.

k12th
+2

Пока нет, там несколько неясных моментов. Но если запускать через babel-node (что нормально для одноразовых скриптов), то будет работать.

k12th
+1

А предложите в питоньем сообществе private/protected — покрутят точно так же. Вопрос привычки и удобства, реальной необходимости ни в перегрузке, ни в сокрытии нет.

k12th
0

Спасибо.