Веб-версия просто написана на первом ангуляре, и как-то слегка кривовато

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

http://formatjs.io/about/ реакт-интл на нем построен + messageformat наработки в нем же + поддерживает небезызваестная компания + сотрудники этой компании и мейнтейнеры — основные чуваки из tc39, которые занимаются ecma-402

поэтому мессаджформат.жс не нужен

поэтому мессаджформат.жс не нужен

+1

btw react-intl тоже не нужен имхо

кор либ вполне достаточно http://formatjs.io/github/#core

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

сейчас хз актуальны ли они, но осадочек остался

http://formatjs.io/about/ реакт-интл на нем построен + messageformat наработки в нем же + поддерживает небезызваестная компания + сотрудники этой компании и мейнтейнеры — основные чуваки из tc39, которые занимаются ecma-402

наес

https://telegram.me/devops_ru

Коллеги, с draft.js кто-нибдуь работает?

Ага

А зачем?

Ага

Подскажи плиз, как из массива вида [ { text: ‘text1’ }, { text: ‘text2’} ] сформировать стейт едитора?

идея для eslint плагина - проверять все компоненты в проекте на уникальность названия. Есть такое? мб кто-то написать и тучу старов сорвать?)

но зачем?

И правда зачем?

чтобы классы при использовании css-modules можно было так писать: Project[name]-[local]

Файловая система не решает эту задачу?

частично решает, но не полностью

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

Кажется на специфику проекта твоего похоже уже

Но кажется по простому можно на уровне шела решить

не только моего) посмотри на фейсбук, у них также

тут eslint исключительно потому что надо определять есть ли в файле react компонент)

Ок

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

Да, я просто не сталкивался )

У нас все в одной папке лежит )

и еще вопрос про flux/redux. Я каждый раз по разному эту задачу решаю, как вы считаете, как правильно. Есть список, есть форма-фильтр. Значения фильтра хранятся в сторе, где правильно debounce ставить на экшн, который с сервера тянет данные?

в компоненте

почему не в экшн креаторе?

и компонент дергает 2 экшна?

или в connect будет норм такой экшн подсунуть?

и еще вопрос про flux/redux. Я каждый раз по разному эту задачу решаю, как вы считаете, как правильно. Есть список, есть форма-фильтр. Значения фильтра хранятся в сторе, где правильно debounce ставить на экшн, который с сервера тянет данные?

В компоненте конечно. Экшен должен быть максимально тупым и ни о каких дебаунсах знать не должен. Это уже конкретная особенность компонента. А в другом месте ты захочешь с другим временем откладываьть вызов или вообще не откладывать его

также можно сказать и про компонент. Компонент тоже хочется, чтобы был максимально тупым

и компонент дергает два экшна, да

Так наличие debounce не делает компонент умнее ) А вот экшен становится сложнее

а в connect не ок решать? Допустим будет onLoad, onLoadMore и onReload = debounce(onLoad)?

ибо в противном случае внутри конструктора компонента идет магия с _.debounce, и по вашему это ок?

Можно и в классе сразу: class A { … handleLoad = _.debounce(options => this.props.onLoadMore(options)); … render() {} }

вот кстати второй вопрос) передавать filter в экшн, или брать из стора?

Из стора

Если он там хранится изначально

> Экшен должен быть максимально тупым Это твои слова. Знание экшна о сторе не усложняет его?

Ну тогда наверно это можно назвать делом вкуса ) Объясню. Если я делаю фильтр в сторе, я изначально закладываю идею изменения фильтра многими другими экшенами. Тогда, чтобы не гемороиться с интерфейсом, я просто буду вынимать все из стора. Все равно у меня там thunk и он прокидывает мне getState. Но если я хочу изменять фильтр только в одном месте, то я не храню фильтр в сторе, и тогда да, надо передавать его как параметры функции

да, это понятно) вообще такие вопросы - это вопрос про личный опыт и набитые шишки. Но ок, тогда так и буду делать)

Туда же - фильтр может быть сложным объектом. Один из рычагов меняет в нем только одно поле. Тогда чтобы перезапросить данные способом с передачей фильтра как параметра функции, мне придется подписаться в компоненте на изменение стора фильтра. В случае с выниманием фильтра из стора в экшене подписываться вообще не обязательно. И компонент становится тупее, что нам и нужно. Просто по мне так тупой компонент важнее тупого экшена ) Пусть уж лучше обращение к стору будет в экшене

я из стора беру, потому что так быстрее тупо

Можно и в классе сразу: class A { … handleLoad = _.debounce(options => this.props.onLoadMore(options)); … render() {} }

А если к моменту срабатывания debounce this сдохнет?

Парни, кто как использует let и const? Я всегда юзаю const где не перезаписываю переменную. Некоторые принципиально не используют const для объектов. Хочу знать мнение сообщества.

Парни, кто как использует let и const? Я всегда юзаю const где не перезаписываю переменную. Некоторые принципиально не используют const для объектов. Хочу знать мнение сообщества.

Некоторые везде хреначат let и не парятся

const не сделает объект иммутабельным

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

const не сделает объект иммутабельным

И это грустно

хотя логически всё верно. Ведь в переменной хранится только ссылка

Посмотрел 10-15 популярных репо на гитхабе, везде юзают const, let только когда перезаписываем переменную.

Посмотрел 10-15 популярных репо на гитхабе, везде юзают const, let только когда перезаписываем переменную.

Тоже так делаю

В Rust например по умолчанию все 'переменные' немутабельные, и там нужно дополнительно указывать, что ты можешь менять их значение

Такой подход выглядит разумным

В мире Java тоже считается хорошим тоном у свойств/методов объектов указывать final всегда

Так что это считается хорошей практикой не только в JS

В мире Java тоже считается хорошим тоном у свойств/методов объектов указывать final всегда

final у методов означает совсем другое: final метод нельзя переопределить при наследовании

ERROR: S client not available

ноп.

чувакк говорит не о методах а о филдах

Final у аргументов методов всего лишь означает, что нельзя в теле метод создать локальную переменную с таким же именем.

Посмотрел 10-15 популярных репо на гитхабе, везде юзают const, let только когда перезаписываем переменную.

Тем временем некоторые наивно думают, что замена var константами и let не приносит пользы http://www.bennadel.com/blog/2949-var-for-life---why-let-and-const-don-t-interest-me-in-javascript.htm

поехавшие

Ну я не большой специалист в Java, знаю лишь, что final запрещает переопределять методы/менять свойства/переменные

так и есть

Ну да, во всех хороших книгах по Джаве рекомендуют делать поля и перменные final. Только это лукавство - на одних final ничего не напишешь, ибо нужно как-то моделировать изменение реального мира в своей программе. И к тому же final делает иммутабельную ссылку, но если она ссылается на объект или коллекцию, то они по-прежнему мутабельны. Правльное решение - это мутабельные ссылки (с чёткой concurrency сематникой) на иммутабельные объекты/коллекции. В Джаве пока нет нормальных иммутабельных коллекций, только copy-on-write. И из ссылок с чёткой семантикой есть тольк AtomicReference

А вот в Clojure есть и хорошие иммутабельные коллекции и несколько типов ссылок (var, atom, agent, ref)

Ну точно по этой же причине я и не везде пишу const, а иногда использую let. Хотя в js кончено можно и на одних const'ах уехать

А если к моменту срабатывания debounce this сдохнет?

Хороший вопрос :) Проверил сейчас - все нормально сработало. Там же this в замыкании сохраняется

Тем временем некоторые наивно думают, что замена var константами и let не приносит пользы http://www.bennadel.com/blog/2949-var-for-life---why-let-and-const-don-t-interest-me-in-javascript.htm

а оно и не приносит))

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

ну, кто код нормальный пишет, а не лапшу, да еще и линтерами пользуется, от const/let ни холодно ни жарко.

А серьезно какой профит от let и const это же все равно в var трансплитится.

Я let использую по назначению, с каким она задумывалась, и просто привык уже ) Например в редьюсерах const reducer = (state = initialState, action) => { if (action.type === SOME_TYPE) { let list = action.payload.map(() => {}); return { ...state, list, listById: keyBy(list, 'id') }; } return state; } Мне просто совесть не позволяет написать var не в начале функции ) И таких конструкций может быть много, а засорять редьюсер объявлением всех вспомогательных переменных в начале функции совсем не хочется при этом. Пусть в итоге все в var транспилится, зато мой код красивый )

А серьезно какой профит от let и const это же все равно в var трансплитится.

Пусть const и транспилится в var, но не даст переопределить этот самый const

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

=)

Можно предположить что в перспективе jit сможет оптимизировать код понимая что тип у const не изменится. также конст удобна прежде для самого разработчика - видно что ссылка\значение больше не изменится.

Просто замечание про "нормальный код" несколько резковатое, мне показалось. "Нормальный код" может быть достаточно личным понятием и +- отличаться.

профит в том что let и var работают по-разному

словно в projs зашел)

Можно предположить что в перспективе jit сможет оптимизировать код понимая что тип у const не изменится. также конст удобна прежде для самого разработчика - видно что ссылка\значение больше не изменится.

тут особо нечего оптимизировать

наоборот при const/let надо еще TDZ учитывать, поэтому они сильно быстрее не будут. разве что после блока можно память подчищать уже. но gc все равно придет когда сам захочет

Авось утечек станет меньше, вся надежда на это.

за счет чего?

есть еще редакторы, которые не ругаются когда var с одним и тем же именем напишешь?

За счет того, что не нужно держать лишнего в памяти.

поподробнее. если я ничего не упускаю, то утечка и возможность освобождения памяти сейчас или через 1с слабо связаны)

и конст с летом не спасают от утечек