Эта.

го учить раст

Он никак не связан с проблемами с перфомансом, вызыванными ошибками в проектировании

на каждый ресайз и вроде бы задача норм, но...

ДОМ-операции всё равно на порядок тяжелее.

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

Так что, не парься, у тебя есть большая фора.

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

Он никак не связан с проблемами с перфомансом, вызыванными ошибками в проектировании

а с другими проблемами с перформансом связан

а потом считать реальный сайз по чайлдам

Погодите, я всё ожидаю момент, когда у него начнёт тормозить рамда с операцией min, прости хоспади

Не тот кейс ваще.

И вот эти операции походу оч много времени занимают

+ еще 10 проверок в таком духе

10?

ну 5-6

10 000 в секунду)

У тебя 10 000 строк, и тебе нужна сортировка + выборка на фронте.

Вот это кейс.

Это минимальный порядок при котором можно заметить хоть какую то разницу

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

И при том я не пожертвовал иммутабельностью. =Р

а дергать мышку юзер может очень часто

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

и это сразу видно

Это должно решаться силами css, если нужна связь с данными - то css-in-js (jss точно будет достаточно быстрым)

Это должно решаться силами css, если нужна связь с данными - то css-in-js (jss точно будет достаточно быстрым)

+++++++

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

Вот да.

Ну может быть я плохо обьяснил

Это должно решаться силами css, если нужна связь с данными - то css-in-js (jss точно будет достаточно быстрым)

а какое у тебя мнение насчет styled-jsx?

Много паранойи в этом треде.

Чё, опять чёт учить придётся?

так вродь стайлед компонентс хайпуют сейчас

не ?

Ну как.

мне вообще поебать

мне апи не нравится

я пишу, и оно работает

Ща набегут.

если какие-то проблемы - ну переписываю с меньшим количеством сахара, и все снова работает

Мой коллега сильно критикует производительность jss и SC.

так вродь стайлед компонентс хайпуют сейчас

emotion

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

И рекомендует emotion.

я вообще. этим не парюсь ))

Мой коллега сильно критикует производительность jss и SC.

SC - да, jss - нет, и авторы оч этим гордятся

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

Ну вот теперь ситуация изменилась

SC - да, jss - нет, и авторы оч этим гордятся

Ну, его аргументы, что эмоушен нагибает jss сильно.

Не стоит пытаться решать организационные проблемы кодом))

Ну, его аргументы, что эмоушен нагибает jss сильно.

Может быть

а какое у тебя мнение насчет styled-jsx?

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

(пруфов нет)

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

Своеобразный подход) Не знаю даже как к нему относиться

а не как в ск сначала создаёшь компонент а потом еще один компонент но со стилями

Та у тебя всё равно получается компонент со стилями

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

он еще прост и быстр

мне говорили что он кривой

хз чем это выражается

вообще самый норм - styletron

О ребят, есть архитектурный вопрос. Есть компонент и есть тулбар для него. Тулбару надо знать про координаты компонента (для некоторых может понадобиться доп инфа). Задача стоит в том что бы сделать позиционирование тулбаров через редукс. 1. стоит ли передавать рефку компонента что бы знать про позицию компонента ? 2. Как сделать так что бы для всех тулбаров было позиционирование относительно компонента, но что бы его можно было переопределить ?

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

вообще самый норм - styletron

здесь видимо тоже самое что и у sc

ля

очень хочется заюзать препак)

он пиздецки подходит под мою мыслю "разделяй и властвуй"

Пока из хардкорных методов оптимизации тащит closure-compiler, но это настолько чужеродная хрень, что довольно сложно представить большой проект, который бы успешно оптимизировался им в advanced mode

ну если он на кложе написан, то прям изи

Внезапно прям ?

там при неверном интероропе бывает, что после advanced что ничего не работает (переименования, все дела), но решаемо

purescript кстати безопасен в плане advanced mode

То есть всё по канонам

я точно перейду на пурсу

Но кложур компилер не понимает его тайпклассы (как реальные классы, просто создаваемые из функции, ну такой олдскул типа), поэтому пока не 100% типизирует

я тут пока случайно открыл свои сообщения, а я туда скидывал посты нашего Зигохистоморфа про рекурсивные схемы

Пока из хардкорных методов оптимизации тащит closure-compiler, но это настолько чужеродная хрень, что довольно сложно представить большой проект, который бы успешно оптимизировался им в advanced mode

у Angular команда CLI работает над интеграцией (переписывают куски фреймворка чтобы лучше с CC работало)

и короче вот

у Angular команда CLI работает над интеграцией (переписывают куски фреймворка чтобы лучше с CC работало)

Ага, я читал уже, норм

Что тут?)

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

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

??

Кто-нибудь может подсказать, как в bookshelf+knex реализовать такое условие? Model.where({ cond1: true, cond2: false, num1: { $gte: 5, $lte: 8 }, num2: { $gte: 5, $lte: 8 } });

О ЩИ~~

> format @"Wurble %d %d %s" 10 20 30 Error found: Could not match type String with type Int while trying to match type Function String with type Function Int

http://kcsongor.github.io/purescript-safe-printf/

да, это круто

http://kcsongor.github.io/purescript-safe-printf/

Как в рамде сделать, чтобы функция выполнилась после N вызовов? В лодаше есть before/after методы, а в рамде? Просто каррировать на arity+1 не гуд - лишний аргумент

const callAfterN = n => f => n == 0 ? f : () => callAfterN(n - 1)(f); const f = () => console.log("done"); const g = callAfterN(2)(f); g()()(); // Done ?

const callAfterN = n => f => n == 0 ? f : () => callAfterN(n - 1)(f); const f = () => console.log("done"); const g = callAfterN(2)(f); g()()(); // Done ?

ну по-любому там уже есть что-то подобное написанное, я не хочу плодить utils.js

Я чёт не очень понял суть замысла)

(n, f, a, b) => () => () => ... () => f(a, b)

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

.then

как ты себе представляешь сделать это функционально?)

Через ST