• Как сделать автоперенос текста в Node.JS?

    Можно готовую функцию взять, https://lodash.com/docs/4.17.15#words и потом из массива новые строки составить
    Написано
  • Как сделать автоперенос текста в Node.JS?

    Напишите алгоритм. Например, формирование набора строк не превышающих ширины канваса. Сначала дробите строку по словам, потом формируете раздельные строки нужной длины.
    Написано
  • В чем практические отличия null от undefined?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Это не конкретно про использование `null`.
    С таким же успехом можно проинициализировать с null или false, и условие выхода сделать на проверку значения.

    Вопрос, почему именно undefined, или почему именно null использовать в примере :)

    Мы можем сказать при `var a = null` что значение так и не найдено по результату работы цикла (если значение так и осталось null).
    При `var a` мы скажем ровно тоже самое, даже если там `undefined`.
    Написано
  • Как восстановить глобальный метод после теста в Jest?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Компоненты работают с глобальными переменными окружения.
    Написано
  • В чем разница между One-Way Binding и Two-Way Binding?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    >При двусторонней данные будут менять при вводе в поле ввода.
    Это будет тоже изменением данных через код, т.е. и при изменении из кода меняется интерфейс, и при изменении из формы вызывается этот же код и меняется интерфейс, и этот алгоритм один и для односторонней связи, и для двухсторонней, потому что и там и там это работает через функцию обратного вызова (иначе технически нельзя).

    Пример про отсутствие биндинга верный, но это не живой пример потому что все формы обрабатываются (в 99% процентов случаев кодом).

    @profesor09
    Написано
  • В чем разница между One-Way Binding и Two-Way Binding?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Что такое правка логики работы с данными?

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

    xmoonlight
    Написано
  • В чем разница между One-Way Binding и Two-Way Binding?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Пример хороший, но технически не получается его наложить. Технически педаль сама не может отпуститься, потому что браузер не умеет писать данные форм в модели без нашего участия. В этом и вопрос, как-раз. Если это тоже делаем мы, точно так же, как и в односторонней привязке, тогда что такое двухсторонняя привязка?

    Andrew
    Написано
  • Могут ли контейнеры содержать классы и разметку?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Чистый это значит всегда одинаковый результат при одинаковых данных на входе. Конечно, компонент не может быть чистым в прямом смысле, ведь есть дочерние компоненты, но как определение, оно применимо к компоненту.
    Написано
  • Могут ли контейнеры содержать классы и разметку?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Вариантов тонна, вопрос какой лучше. Сделать кашу, делать как хочется мы всегда успеем, но мы как специалисты должны двигаться в сторону идеального (так не бывает, конечно), и всегда искать лучший вариант.

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

    Комментарий супер, но вопрос всё еще открыт, потому не отмечу решением, потому что интересен именно опыт людей, конкретные решения, чтобы произошел обмен опытом и можно было пересмотреть свое решение более взвешенно.

    Спасибо
    Написано
  • Могут ли контейнеры содержать классы и разметку?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Я написал выше. Вы не можете переиспользовать его, значит компонент жесткий. Это как прибить доску гвоздями к табуретке, а потом думать как её снять и прикрутить к стене. В таком случае вы делаете доску, которая содержит технические отверстия, и если они подходят и к стене, и к табуретке, вы можете спокойно прикрутить доску куда-угодно.

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

    Павел Диденко
    Написано
  • Могут ли контейнеры содержать классы и разметку?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Но становится помесью. Если вам потребуется три инстанса с тремя разными данными, вы уже не сможете этого сделать, потому что данные зашиты в компонент. Значит он уже не полностью презентативный. Поэтому потерялась гибкость переиспользования компонента. Я понимаю что в этом и идея разделения этих типов компонентов.
    Написано
  • Могут ли контейнеры содержать классы и разметку?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Отсюда: https://redux.js.org/basics/usage-with-react#prese... + https://medium.com/@dan_abramov/smart-and-dumb-com...

    Лично мое мнение:

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

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

    Павел Диденко
    Написано
  • Как правильно сделать локализацию на React?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Да, я неправильно готовил этот модуль.
    Нашел как обойтись без defineMessages, стало намного проще.

    https://stackoverflow.com/questions/37217125/how-t...
    Написано
  • Как правильно сделать локализацию на React?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Мне не нравится что нужно сначала составлять общий список ключей через defineMessages, а потом нужно еще отдельно держать локализации, в которых должны быть переводы по ключам из defineMessages, причем ключи могут быть разные.

    Поэтому фактически вместо создания пары ключ + перевод, делается одна пара ключ + описание ключа в defineMessages, и вторая пара ключ + перевод. Фактически, defineMessages делает прокси-объект (грубо), и он нам не нужен, но избавиться от него, видимо, никак.

    Проще было бы писать
    <FormattedMessage id="foo">Foo default text</FormattedMessage>
    , и создать один файл ru_RU.json с { "foo": "Перевод Foo" }, и всё.

    Если вы знаете как выбросить defineMessages, подскажите, это было бы супер.

    s0xzwasd
    Написано
  • В каких случаях использовать Redux?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    >кто из них должен владеть состоянием?
    Никто, они все зависят от данных в сторе, одни напрямую, другие через свойства компонента.

    >но что будет, если он не создается пока массив пустой?
    Будет сообщение что список пуст, а в лучшем варианте, будет виден лоадер на период загрузки данных (если они должны загрузиться)

    >а отдельный элемент наверняка будет с возможностью редактирования, а это уже локальное состояние, которое придется как то согласовывать с родительским компонентом список
    Здесь есть одно огромное НО, в виде завязки на данные стора, т.е. переиспользовать компоненты будет нельзя, если завязывать редактор напрямую на данные из стора. Если есть редактор текущего пользователя, например, то нельзя ему скормить другую модель и получить на выходе обновленную модель после редактирования. Это делает решение максимально жестким. Поэтому и делаются выбросы данных в родительский компонент через функции обратного вызова. Это создает связь между компонентами, но остается огромное пространство для маневров по вариантам использования компонентов, поэтому это не проблема.

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

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

    Может быть я не понял сообщения, но вообще не вижу проблем при реализации. Данные в сторе общие, связи только на уровне функций обратного вызова (что обеспечивает переиспользуемость компонента и это хорошо, это базовая практика для любых компонентов, см. API компонентов любого UI kit'а). В вашем примере ни счетчик, ни форма создания Todo, ни список друг о друге ничего не должны знать, все только на стор завязыватся. Локальное состояние будет только у редактора конкретного Todo. Можно еще переделать форму создания Todo, чтобы она не на стор завязывалась, а наружу данные выбрасывала через функцию обратного вызова.
    Написано
  • Нужно ли помещать в стор все состояния компонента?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    cocomuffin, в таком случае страница, допустим, будет перезагружена посреди загрузки, и получим что данных в стопе нет, спиннер будет виден, а запрос вовсе не отправлен, и спиннер будет крутиться бесконечно.

    Получается надо отслеживать такие кейсы, а это лишняя головная боль. Опираясь только на данные без состояний, пользователь бы увидел что данных нет и началась бы новая загрузка данных.

    Кода меньше, сложности меньше, сценариев для обработки меньше, значений в сторе меньше.
    Написано
  • Нужно ли помещать в стор все состояния компонента?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Да, и поэтому у меня и вызывают вопросы многочисленные доки, где хранят намного больше данных, временных.
    Может быть есть кто так делает (хранит локальные значения в сторе), и может обяснить для примера, зачем они это делают.
    Написано
  • Нужно ли помещать в стор все состояния компонента?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Тогда, может быть вы можете обьяснить, какой мотив делать так (?): https://redux.js.org/advanced/async-actions
    Они в стор передают isFetching, didInvalidate, которые по сути временные значения на период загрузки данных или ввода пользователя.

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

    Они пишут:
    >For every list of items, you'll want to store isFetching to show a spinner, didInvalidate so you can later toggle it when the data is stale, lastUpdated so you know when it was fetched the last time, and the items themselves. In a real app, you'll also want to store pagination state like fetchedPageCount and nextPageUrl."

    Но обьяснения считай нет.
    Написано
  • Как разделить код работы с состоянием приложения?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Я тоже к этому пришел, да.
    Написано
  • Как разделить код работы с состоянием приложения?

    yakimchuk-ry
    @yakimchuk-ry Автор вопроса
    Да, проблема может быть в производительности.

    Я смотрю на Redux, на локальное состояние компонента, и по идее от локального состояния можно отказаться в пользу Redux. Получится больше контроля, отказ от хуков React, четкий поток действий, доп. инструменты для отладки, т.е. будет удобно, и в перспективе еще и управление состоянием можно в памяти хранить, вплоть до мелочей (если понадобится).

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

    Сергей Сунцев, что думаете?
    Написано