ну так в том-то и дело, что их все описывать не выйдет

а, уже не выйдет?)

а иногда нужны какие-то точечные кастомизации

а что тогда выйдет описать?

потому что это делать нужно иначе)

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

иначе описывать 200 свойств реально сдохнешь

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

и здесь типизация и интерфейсы очень кстати

и опять говорю - это миф

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

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

не очень понял, как это связано с мифами

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

этого делать не нужно

ну как не нужно

вот у тебя етсь такой инпут

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

а если какой-то умник сделает addon {width: 0; height:0}, он сломает компонент. интерфейс не должен такого позволять, jss этой проблемы не решит. а раз не решит - зачем мучаться?)

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

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

а если какой-то умник сделает addon {width: 0; height:0}, он сломает компонент. интерфейс не должен такого позволять, jss этой проблемы не решит. а раз не решит - зачем мучаться?)

а для этого как раз и нужны стилевые интерфейсы и типизация

чтобы флоу сказал тебе, что ты осел и так делать не надо

и подсказал тебе, что делать можно

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

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

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

бэм никак не решает моих проблем, к сожалению)

в каком плане? интерфейс раскладывается на элементы и модификаторы

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

ну а как ты запретишь переопределять display свойство?

если есть типизация (тайпскрипт, флоу), то это можно сделать

декларируя интерфейсы примитивов

блин, надо показывать))

на словах сложно пояснить

и тут вариант, либо делать DSL, аннотации @override (привет java), либо писать ручками 200 полей каждый раз

почему? у тебя может быть какой-то переиспользуемый тип, в котором есть whitelist/blacklist, например

потому что от компонента меняется whitelist/blacklist, например

не сильно, те проблемы, что ты перечисляешь - это общие проблемы. да и как бы дифф есть

ок, будет интересно увидеть твой проект)

суть в том, что мне хотелось бы знать, что какой-то StyledComponent предоставляет мне возможность изменять свойство color у кнопки primary, когда она hovered и не хочется при этом, создавая этот компонент, тратить много времени на это ну и кажется, что это возможно)

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

привет всем, кто-нибудь пользовался https://github.com/treycordova/nativejsx ?

Страсти то какие, как же они все ещё не сгорели с десктопными приложениями?) Распределение нагрузки по тредам - это наоборот облегчение для компьютера, потому что делать расчёты в том же потоке, в каком работать с UI - это прямой путь к тормозам

Распихивать расчёты по потокам имеет смысл, когда идёт сильная нагрузка на процессор и процессор имеет несколько ядер. Иначе скорее всего произойдёт лишь падение производительности. А десктопные приложения обычно выносят в отдельные потоки длительные, но не обязательно загружающие CPU операции, например операции с сетью. В случае JS это обычно не нужно из-за его асинхронной природы.

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

Распихивать расчёты по потокам имеет смысл, когда идёт сильная нагрузка на процессор и процессор имеет несколько ядер. Иначе скорее всего произойдёт лишь падение производительности. А десктопные приложения обычно выносят в отдельные потоки длительные, но не обязательно загружающие CPU операции, например операции с сетью. В случае JS это обычно не нужно из-за его асинхронной природы.

Не по потокам, а в поток, отдельный от ui в первую очередь. Он банально мешает

http://web-perf.github.io/react-worker-dom/ Тащемта, проще своими глазами убедиться

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

А я сам такие вещи делал, например. Криптография

А есть какие нибудь замеры производительности?

Бенчмарк DBMonster с воркерами не запустился в фаерфоксе, в хроме наблюдается повышение производительности аж на 1-2 ФПС!!! Охренеть ускорение.

А, есть вроде че то

А я сам такие вещи делал, например. Криптография

Не факт, что криптография такая тяжёлая, что будет тормозить UI. Хотя это криптография на JS.

Народ, подскажите по webpack'у делаю import скрипта в главный app.js, скрипт не отрабатывает, может есть какие-то нюансы что в скрипте прописывать, функцию или что?

https://t.me/webpack_ru

Только там все злые сидят

и не помогают))

https://t.me/webpack_ru

Спасибо, я добрый, буду помогать))

Бенчмарк DBMonster с воркерами не запустился в фаерфоксе, в хроме наблюдается повышение производительности аж на 1-2 ФПС!!! Охренеть ускорение.

А сколько у тебя вообщем ФПС вышел в обоих вариантах?

Не факт, что криптография такая тяжёлая, что будет тормозить UI. Хотя это криптография на JS.

Результаты расчёта ключа для большинства известных big number библиотек - от 8 до 40 секунд. У меня - максимум две, а с воркерами дополнительно повышается отзывчивость интерфейса в этот момент.

Для иллюстрации - валидация результата - это сравнение числа с 2 в степени 2048 - 64, это 496 разрядов

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

Да

Если такой компонент один

Например компонент content и в нем контейнер githubRepos

Я бы сказал, что такой компонент будет контейнером уже тоже

Если чайлдом

То всё ок

ERROR: S client not available

Думаю все же Андрей про импорт контейнера внутри файла компонента

Иначе хок какой-то

Ну это может быть и просто компонент Layout

например. не контейнер

Да

Думаю все же Андрей про импорт контейнера внутри файла компонента

Компоненты - глупые и не знают ни о какой бизнес логике. Контейнеры - знают. Если ты импортишь контейнер в компонент, то внезапно он становится завязанным на бизнес логику.

Ну сейчас у меня два варианта решения этой проблемы: либо создать один контейнер, который будет пропсами прокидывать данные в свои компоненты или создать компонент, который в body будет принимать (в моем случае) контейнеры

Какой из них лучше, или есть еще какие-то?

делай как удобно =)

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

делай как удобно =)

А best-practice?)

Во втором случае

Во втором случае

Да, это уже будет в контейнере

А best-practice?)

тебе ехать, или шашечки?) в реальном проекте понятия контейнеров и обычных компонентов пропадают. есть UI-компоненты (инпут, кнопка, список юзеров) и просто компоненты

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

Разбей на три компонента

тебе ехать, или шашечки?) в реальном проекте понятия контейнеров и обычных компонентов пропадают. есть UI-компоненты (инпут, кнопка, список юзеров) и просто компоненты

Ок, в любом случае спасибо

Разбей на три компонента

почему три?

. сверху еще один контейнер, который передаст контейнеры через чилдрен

если будет легче - оберни компонент в connect()(Component), чтоб было)

Ну как ты говорил во втором случае. Это как вариант

Или забей

Видимо, проще забить

Привет! Может кто пытался прикрутить eslint airbnb в create-react-app? что-то не хочет нормально работать. в консоли не кидает ошибки, в vs code вроде норм, но с импортами беда

Спасибо за хелпу в борьбе с "перфекционизмом"...

Привет! Может кто пытался прикрутить eslint airbnb в create-react-app? что-то не хочет нормально работать. в консоли не кидает ошибки, в vs code вроде норм, но с импортами беда

Посмотри package.json, там прописан еслинт конфиг от реакт-апп

Привет! Может кто пытался прикрутить eslint airbnb в create-react-app? что-то не хочет нормально работать. в консоли не кидает ошибки, в vs code вроде норм, но с импортами беда

А в react-boilerplate/package.json как настроить airbnb

Ребят, а причем тут package.json если для конфига используют eslintrc? Ну в общем кажется нашла ответ на свой вопрос тут https://github.com/facebookincubator/create-react-app/issues/1355 блин, странная концепция не линтить стиль кода

можно и в package.json описать правила, eslintConfig вроде ключ должен быть тогда

prettier в моде ж

пробовала "extends": ["airbnb"] в package не помогает. Оу, не в курсе моды, спасибо гляну )