Так, пацаны, давайте застабилизируем библиотеку

И я пойду её писать

Чё нужно от форм? 1) объект со значениями 2) валидация налету 3) валидация на сабмите (серверная/локальная) 4) форматирование Райт?

библиотеку для <Input onChange={...} />?:)

Да

Коротко о редакс-форм

ну ээ скорее вопрос как state организовать Парсить ли глубокие пути вида name="post.user.name" И где держать инфу о валидации

Да, райт

@Misaka need help

Ты работал с редакс-форм, объясни как лучше

Что?

А что пояснить то надо?

Я пишу библиотеку для форм без редакса, какие у тебя были проблемы с редакс-форм?

+ как организовать стейт?

Pristine/dirty руками не ставились.

name="post.user.name” ok?

Ну да.

Pristine/dirty руками не ставились.

?

Ну, только редакс форм сам определял, что форма поменялась или очистилась.

Помню еще проблема с массивами была

Помнишь, картинки?

Ну да

И toggle

?

Ну, когда ты реордерил массив, например, dirty не ставился.

Хотя данные поменялись.

А зачем мы список пикч хранили в редакс-форм?

Мне кажется это слегка нелогичным

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

Потому что он приходил на форму. Как данные с сервера.

У нас весь ввод/вывод от юзера через redux form был.

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

Ну да.

I see, популярная проблема, надо над ней подумать

Кстати, пацаны, активно участвуйте в опенсорсе

Кстати, хорошо замативировал, +1 pr с починкой бага у eslint-react-plugin.

И есть нормальные статьи по AST? а то приходится самому догадываться и в слепую.

Надо элегантно разделить формы и другие компоненты, но при этом учесть, что они всё равно приходят/уходят как один стейт

(в чем проблема — у нас есть список картинок, который приходит как images: [], но управляется драгндропом компонентов)

И т.к. остальная страница это чисто форма, то и с этой хуйней мы тоже через redux-form работали

Думаю, у многих есть такая проблема?

Бля, интересная задача. Как элегантно разделять и смешивать стейт.

Кстати, еще немного об опенсорсе http://elliot.land/readme-driven-development

Чё нужно от форм? 1) объект со значениями 2) валидация налету 3) валидация на сабмите (серверная/локальная) 4) форматирование Райт?

не перерендеревать филды, который не были затронуты

и тоже думал взяться за написание формы для опенсорса + по работе нужно

Чё нужно от форм? 1) объект со значениями 2) валидация налету 3) валидация на сабмите (серверная/локальная) 4) форматирование Райт?

сервер-сайд валидации для определённых полей на лету

сервер-сайд валидации для определённых полей на лету

Зачем?

Не считая валидации логина

На уникальность

Очень частое требование, например, проверка уникальности email

либо какая-нибудь хитрая валидация телефона

сервер-сайд валидации для определённых полей на лету

тогда уже поддержка промисов при валидации

proof of concept

поэтому некоторые (вполне законно возмно) говорят что оно "обречено")

Основная проблема cycle.js это то что на каждый чих, на любое изменение будет генерироваться виртуальное дерево всего приложения (проблема которую как раз и решают redux или mobx). То есть не шаблон подписывается на потоки и точечно обновляется (как это сделано например в yolk) а потоки генерируют дум и их комбинация в итоге сводится к генерации virtual dom всего приложения на каждый чих

Вообще не с того фронта зашел решать проблему, дело не совсем в формах

Короче, нужен диффер между двумя стейтами — оригинальным и мутированным. Втором стейт можно насиловать как угодно и откуда угодно (формы/прямые вызовы .toggle()/whatever), главное, что нужно — понимание, как они отличаются (вот эти все pristine/dirty и т.п.).

Ну а формы, соответственно, используют этот подход и все счастливы

Основная проблема cycle.js это то что на каждый чих, на любое изменение будет генерироваться виртуальное дерево всего приложения (проблема которую как раз и решают redux или mobx). То есть не шаблон подписывается на потоки и точечно обновляется (как это сделано например в yolk) а потоки генерируют дум и их комбинация в итоге сводится к генерации virtual dom всего приложения на каждый чих

соглашусь, я тоже вижу тут потенциальную проблему

Основная проблема cycle.js это то что на каждый чих, на любое изменение будет генерироваться виртуальное дерево всего приложения (проблема которую как раз и решают redux или mobx). То есть не шаблон подписывается на потоки и точечно обновляется (как это сделано например в yolk) а потоки генерируют дум и их комбинация в итоге сводится к генерации virtual dom всего приложения на каждый чих

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

по идее да, так по-началу считалось и должен работать v-dom

но как это будет работать при очень интенсивном потоке изменений?

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

ERROR: S client not available

Php Storm и web storm говорят уже не так актуален

А что из иде актуально для js?

vs code

А проблема webstorm в том, что платный, или еще какие-то у этого vs code есть киллер фичи?

vscode - очень очень быстрый

А проблема webstorm в том, что платный, или еще какие-то у этого vs code есть киллер фичи?

Платный?

Зачем переспрашивать очевидные вещи? Если есть, что сказать по теме - говорите сразу, а генерить чушь я и сам горазд

vscode - очень очень быстрый

А можно пример проекта в цифрах (размер, количесвто файлов, фиг знает), где чувствуются тормоза webstorm? Я просто пишу на webstorm, доволен как слон, вообще тормозов не вижу

А можно пример проекта в цифрах (размер, количесвто файлов, фиг знает), где чувствуются тормоза webstorm? Я просто пишу на webstorm, доволен как слон, вообще тормозов не вижу

+

А можно пример проекта в цифрах (размер, количесвто файлов, фиг знает), где чувствуются тормоза webstorm? Я просто пишу на webstorm, доволен как слон, вообще тормозов не вижу

Естественно не видишь :) без сравнения сложно понять. Работаю где-то с 10 проектами ( часто приходиться переключаться - а это просто УЖАС как медленно в webstorm ) каждый от 10 до 30 тысяч строк кода Индексация проекта ( чтобы прыгнуть к файлу ) проходит очень долго, печально долго - в vscode этого просто не замечаешь, редактор очень медленный, поиск тоже Все познается в стравнении. Меня WebStorm перестал устраивать вот и начал искать что побыстрее. Если вам хватает то сидитите себе на здоровье. Для меня важный фактор - скорость.

Прикольно, спасибо

У меня вот vscode на маке иногда залипает и ребутается. Из плагинов наверное только еслинт. Кто-нить встречал такое?

Естественно не видишь :) без сравнения сложно понять. Работаю где-то с 10 проектами ( часто приходиться переключаться - а это просто УЖАС как медленно в webstorm ) каждый от 10 до 30 тысяч строк кода Индексация проекта ( чтобы прыгнуть к файлу ) проходит очень долго, печально долго - в vscode этого просто не замечаешь, редактор очень медленный, поиск тоже Все познается в стравнении. Меня WebStorm перестал устраивать вот и начал искать что побыстрее. Если вам хватает то сидитите себе на здоровье. Для меня важный фактор - скорость.

а можно объяснить, что тут сказано "в vscode этого просто не замечаешь, редактор очень медленный, поиск тоже" а то выглядит так, что вс код медленный все время и потому не замечаешь, что и индексация идет долго

а vim-binding'ами пользуется кто? А то в vscode с ними совсем плохо :( Я думал в атоме всё не особо с этим, но в сравнении с vscode всё очень даже хорошо

да имелл введу индексацию и поиск в WebStorm

В остальном конечно быстрота и работа с ts в vscode впечатляет

В остальном конечно быстрота и работа с ts в vscode впечатляет

Что такое ts?

typescript

typesrcript наверное

аааа

Естественно не видишь :) без сравнения сложно понять. Работаю где-то с 10 проектами ( часто приходиться переключаться - а это просто УЖАС как медленно в webstorm ) каждый от 10 до 30 тысяч строк кода Индексация проекта ( чтобы прыгнуть к файлу ) проходит очень долго, печально долго - в vscode этого просто не замечаешь, редактор очень медленный, поиск тоже Все познается в стравнении. Меня WebStorm перестал устраивать вот и начал искать что побыстрее. Если вам хватает то сидитите себе на здоровье. Для меня важный фактор - скорость.

согласен,у меня такая же ситуация, я переодически выхожу и открываю снова WebStorm (

почему-то память течет

и это уже всю жизнь на windows проблема

согласен,у меня такая же ситуация, я переодически выхожу и открываю снова WebStorm (

я как-то 3 гб видел, но я его не рестарил около недели

WebStorm на Mac часто ругается на то что память закончилась ( правда упираеться во внутренний лимит 512 mb ), и все начинает работать еще медленне :/

3гб. Вам бы в visual studio поработать?

А так, vscode по-моему хуже, веб шторма. Для работы с тайпскриптом

а ещё в атоме такой плюс есть, которого увы нет в vscode: если изменить что-то файле, скажем, добавить символ, то сверху файл отображается как "несохраненный" (что и должно быть) Если потом этот символ удалить (не "отменить" действие, а именно удалить), то атом понимает, что файл в том же состоянии, в котором и был сохранён и уже не показывает сверху файл как "несохраненный". Ужасно удобная вещь на мой взгляд )

WebStorm на Mac часто ругается на то что память закончилась ( правда упираеться во внутренний лимит 512 mb ), и все начинает работать еще медленне :/

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

а ещё в атоме такой плюс есть, которого увы нет в vscode: если изменить что-то файле, скажем, добавить символ, то сверху файл отображается как "несохраненный" (что и должно быть) Если потом этот символ удалить (не "отменить" действие, а именно удалить), то атом понимает, что файл в том же состоянии, в котором и был сохранён и уже не показывает сверху файл как "несохраненный". Ужасно удобная вещь на мой взгляд )

Это нормально. Все продукты мелкомягких так реагируют на изменения

с каждым апдейтом +1 .$ в конце

Это нормально. Все продукты мелкомягких так реагируют на изменения

а я даже не знаю, webstorm в этом плане себя так же как атом ведёт?