@dreamerinnoise а если пока без TS?

@chicoxyzzy haters gonna hate?)

или есть аргументы против?

ну без них можно нормально жить и код фьюче-прууф

вообще без любого сахара можно жить. особенно того, что до stage 3

когда они сломаются после перехода на stage 3 в es, тогда начну

да вот без них не могу добиться такого синтаксиса https://github.com/glortho/react-keydown#for-methods-decorate-with-keys-that-should-trigger-method

можно как-то через hoc красиво сделать?

мы используем их для описания виджетов в системе. кастомные декораторы помогают нам при сериализации/десериализации.

всегда можно в конструкторе ляпнуть this.myMethod = myDecorator(this.myMethod)

+

но мы юзаем декораторы ))

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

да вот без них не могу добиться такого синтаксиса https://github.com/glortho/react-keydown#for-methods-decorate-with-keys-that-should-trigger-method

this.submit = keydown('enter')(this.submit);

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

ну может и не затронет

некрасиво :) @gusnkt

да никак вы не почините) будете жить на babel-plugin-decorators-legacy

:D

да никак вы не почините) будете жить на babel-plugin-decorators-legacy

в ts запихну, ага

мне кажется текущее удобным(и привычным), потому юзаем

Поясните за митап по Реакту. Он будет?

в общем, попробуем в конструкторе забиндить, спасибо @mkusher @gusnkt

да никак вы не почините) будете жить на babel-plugin-decorators-legacy

Ошпарился как-то об эту ересь, когда бабель был ещё не бабель.

С тех пор отсебятину не юзаю из принципа.

да нормас) stage-0 и вперед)

как же вы без бинд оператора в реакте!!!

СТРАДАЕМ!!!

как же вы без бинд оператора в реакте!!!

А что за оператор?

::this.foo

СТРАДАЕМ!!!

у меня stage -1 https://domenic.github.io/proposal-import-function/

эм, а чем System.import не подошел?

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

System.import отлично работает и на чанки бьётся теперь.

где работает?)

хз, мне всегда require.ensure хватало

В вебпаке

втором

угу, а ничего, что спека не готова?) зато две реализации есть) вебпак и системжс)

ни одна, ни вторая с реальностью общего не имеют

потому что никакого систем.импорта нет

и, надеюсь, не будет

мотивация и Систем.импорт траблы тут же: https://github.com/domenic/proposal-import-function#motivation-and-use-cases

import довольно логично выглядит) и его так-то заполифилить прям легко

Народ, подскажите плз название rule eslint - ограничивающий кол-во return в одной функции

заполифиллить как раз нельзя

можно транспильнуть только

только вот системам сборки заколебешься про него рассказывать

import — зарезервированное слово

так что тут без полифиллов

если он не заменит System.import, то может на более низком уровне им же юзаться

это как раз недостающая часть для связи спек лодера и модулей

System.import отлично работает и на чанки бьётся теперь.

он не умеет именованые чанки, поэтому нет смысла его использовать

но зачем System.import тогда вообще?

а есть большая разница, назвать import/System.import?

есть конечно

?

ты на беме пишешь стили ?

не, css-modules

а есть большая разница, назвать import/System.import?

да. написано же в ридми в репке

System.import — это функция жс, которая должна в энве лежать в глобале

import() — синтаксическая конструкция, которую энв может интерпретировать как ему удобно и наиболее оптимально

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

и на деле это будет функция))

есть хоть одна синтаксическая конструкция, которая выглядит как функция, но ей не является в js?))

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

^ в случае js ф-ии (System)

ERROR: S client not available

но это не синтаксическая конструкция, а функция. у функций тоже есть спеки

например fetch

import() — это не просто функция

т.к. import - зарезервированное слово

и оно имеел лексическое значение

fetch — это window.fetch

import — это не window.import

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

поэтому я бы был больше за System.import, вместо волшебной import

это, кстати, плюс к скорости реализации. одно дело написать функцию, другое дело поменять парсер

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

любое зарезервированное слово может являться свойством объекта

т.к. это строка

точнее именем свойства объекта

я понимаю. я к тому что это какая-то фигня, не понятно зачем.

php попахивает, у них тоже можно require './foo' и require('./foo')

для модулей

это, кстати, плюс к скорости реализации. одно дело написать функцию, другое дело поменять парсер

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

и было сделано еще когда зарезервированные слова появились)

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

и как раз так import будет не магическим, а описанным спекой языка

а в случае ф-ии в глобале будет магия

как в случае фетча того же

которого в ноде нет

эм, в ноде и window нет)

и правильно

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

mjs из-за отсутствия связи между загрузчиком и языком хочет появиться

и никто не знает как связать глобальные функции с языком

а так вот она связь

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

это вообще не так)

и поведение везде будет одинаковое, потому что описано в спеке es