150мб в с, вместо стандартных 115?

вот этих чуваков гляньте кому надо

доллар еще не упал тогда =) сейчас может и подороже

У меня 1700мб в с

они неттопы аля макмини делают полностью совместимые с хакинтошем

5 лет назад была ссд с 550 мб в сек

Ниже этого никак нельзя, у всех миллион мелких файлов при сборке. Он же крякнет!

они неттопы аля макмини делают полностью совместимые с хакинтошем

+1

У меня был Dell с Core i3, я просто взял образ osx и поставил. без кекстов и всего такого. ПРосто надо комплектующие выбирать такие, какие есть в одной из моделей mac mini/macbok

Правда есть нюанс конечно, клавиатура при установе работает только внешняя usb

но это мелочь я ноут как неттоп юзал.

Ноуты с хакинтошем извращение, а стационарники тема. Было два ноута с хакинтошем - достали. Хотя работало все.

Ноут - стационарник.

Тачпада и клавы нет)

Не знаю в общем как вы, а по мне macos в виртуалке это адовый ад.

Ноуты с хакинтошем извращение, а стационарники тема. Было два ноута с хакинтошем - достали. Хотя работало все.

чем достало то?

У меня все работало. Потом обновился до последней версии и перестал работать сон. Сказали жди обновления оси, у всех не работает)) помучался.. Хотя был i7 16gb iris pro 5200(самая поддерживаемая конфигурация среди ноутов и мощая === pro 15") + 2 ssd: он и графически и всяко летал с маком

Зашел сравнить на яндекс ноуты: хорошие экраны и начинка от 105 тыс(i7, ips, 16 gb, ssd(обычный не экстра), windows ?, что-то плохое они точно воткнут или тач или динамики). Решил шикануть и взял за 120 новый в пленочках(повезло) pro 15" 2015, 512gb и понял что это давно было извращением

Небольшая переплата стоит того

От тача до динамиков и удовольствия за работой на нем

Похвастался в общем!

Пересчитал на месяцы использования и зп)

И понял что ликвидность через 2 года будет у него, у другого станет равна нулю))

Недавно рекомендовали же yup

https://runkit.com/syabro/58cbddc6aa0c0700137ac232

это какое-то странное поведение

кастовать при стринге [1,2] в "1,2"

что по вашему сейчас самое адекватное для optimistic updates в стеке react-redux?

а, нашел strict mode

Еще один вопрос про стилизацию компонентов. Допустим, есть компонент, который должен иметь шрифт. Но этот шрифт уже есть. Как это можно решить? Еще раз подключить в самом компоненте? JSS

Нормально так получать данные с сервака? componentWillMount () { if (this.props.products.length === 0) { this.props.loadProducts() } }

А с бэка не может пустой массив прилететь?

Кстати Марк, вы можете продолжать юзать scss если вопрос лишь в разделении файлов

Не пойму зачем было предложено все на jss переделывать

В чате довольно давно и периодически встречаю вопросы по работе с формами — всякие мучения с redux-form, как преобразовывать данные и т.п. И мне кажется многие мало знакомы с тем, сколько всего удобного даёт нам веб-платформа. Даже используя "uncontrolled" формы мы может сделать очень многое, и я попытался это продемонстрировать в заметке — https://medium.com/@everdimension/how-to-handle-forms-with-just-react-ac066c48bd4f#.eblhz5qm2 я считаю, тут много полезного, но главная мысль такова — всё что угодно мы можем сделать с помощью html API и небольшой помощи реакта.

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

А стили все покомпонентно разбиты, просто бандлятся и тянутся в проект отдельно от основной сборки, так что, тут самое то, чтобы попробовать перегонку в JSS. Верстальщики не обидятся, их нет)

В чате довольно давно и периодически встречаю вопросы по работе с формами — всякие мучения с redux-form, как преобразовывать данные и т.п. И мне кажется многие мало знакомы с тем, сколько всего удобного даёт нам веб-платформа. Даже используя "uncontrolled" формы мы может сделать очень многое, и я попытался это продемонстрировать в заметке — https://medium.com/@everdimension/how-to-handle-forms-with-just-react-ac066c48bd4f#.eblhz5qm2 я считаю, тут много полезного, но главная мысль такова — всё что угодно мы можем сделать с помощью html API и небольшой помощи реакта.

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

вот-вот :) а ещё все норовят засунуть всё в редакс-стейт но главная идея ведь — have a single source of truth for one type of data, а не один стор для любого стейта source of truth для (простой) формы — это собственно сама форма. И помимо её состоянии у неё есть огромное количество очень-очень удобных методов и хелперов

например об этом оказывается знает мало кто:

что у формы есть метод .checkValidity()?

ага

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

такие статейки весьма полезны

В чате довольно давно и периодически встречаю вопросы по работе с формами — всякие мучения с redux-form, как преобразовывать данные и т.п. И мне кажется многие мало знакомы с тем, сколько всего удобного даёт нам веб-платформа. Даже используя "uncontrolled" формы мы может сделать очень многое, и я попытался это продемонстрировать в заметке — https://medium.com/@everdimension/how-to-handle-forms-with-just-react-ac066c48bd4f#.eblhz5qm2 я считаю, тут много полезного, но главная мысль такова — всё что угодно мы можем сделать с помощью html API и небольшой помощи реакта.

А полагаться на ValidityState норм? Мы тут используем

Главное на сервере не забывать проверять

Ну само собой.

А полагаться на ValidityState норм? Мы тут используем

да, норм полагаться на те вещи, которые уже универсально поддерживаются Например поле tooShort есть только в хроме, но самые главные поля — valueMissing, valid, patternMismatch — есть везде А остальные кстати говоря можно эмулировать самим, я планирую позже об это написать

redux-form не нужен? а как быть с более сложными примерами валидации и более сложными формами?

не required и не pattern

использовать более сложные валидации

на собственных компонентах

и с зависимостями между значениями полей

ну или на redux-form

на собственных компонентах

я стал счастлив, когда начал использовать redux-form, перейшовшы с собственных компонент)

да, норм полагаться на те вещи, которые уже универсально поддерживаются Например поле tooShort есть только в хроме, но самые главные поля — valueMissing, valid, patternMismatch — есть везде А остальные кстати говоря можно эмулировать самим, я планирую позже об это написать

полифилить?

я стал счастлив, когда начал использовать redux-form, перейшовшы с собственных компонент)

В итоге меньше кода или думать меньше?

bolerplate появляется по идее или нет?

redux-form не нужен? а как быть с более сложными примерами валидации и более сложными формами?

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

полифилить?

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

>> а что за "более сложный пример валидации"? :) ну, например autocomplete поле, которое подругружает значение с сервера по мере набора, и разрешает только значение, которое есть в списке допустимых значений

>> а что за "более сложный пример валидации"? :) ну, например autocomplete поле, которое подругружает значение с сервера по мере набора, и разрешает только значение, которое есть в списке допустимых значений

ну так это всё внутренние заморочки компонента, экспоузить он должен по сути только onChange, а валидироваться в идеале должен как нативный <select />

ERROR: S client not available

Ребята, как вы фронт юниттестируете? Как данные с сервера в тесты передаете? Или вы их мокаете? А если апи поменялось, моки обновляете?

>> а что за "более сложный пример валидации"? :) ну, например autocomplete поле, которое подругружает значение с сервера по мере набора, и разрешает только значение, которое есть в списке допустимых значений

а для кастомной валидации есть... custom validity )

ну так это всё внутренние заморочки компонента, экспоузить он должен по сути только onChange, а валидироваться в идеале должен как нативный <select />

Ладно

У меня поле это гора хтмл

На выходе жсон в пару кб

Подход ещё актуален? Сорян с телефона, статью до вечера отложил

Подход ещё актуален? Сорян с телефона, статью до вечера отложил

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

У меня композитное поле

Из пяти инпутов

Адрес

Такое пройдёт?

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

и очень удобно пользоваться ArrayField, FormSection

что у формы есть метод .checkValidity()?

А вот этого не знал

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

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

стейт формы строится одним хэндлером из одной строчки: handleChange(e) { this.setState({ [e.target.name]: e.target.value, }); }

Ребята, как вы фронт юниттестируете? Как данные с сервера в тесты передаете? Или вы их мокаете? А если апи поменялось, моки обновляете?

моки, изменения апи, ломающие совместимость, уходят на другой урл (/api/vX.X), это тестируется уже внутри апи, что ничего не сломалось старого

стейт формы строится одним хэндлером из одной строчки: handleChange(e) { this.setState({ [e.target.name]: e.target.value, }); }

А если у меня массив аддрессов? Или массив вариантов товара с их атрибутами?

А если у меня массив аддрессов? Или массив вариантов товара с их атрибутами?

это всё интересные кейсы с разными решениями но по сути задача одна и та же — превратить структуру форму в структуру модели решений можно много придумать, но часто достаточно простой formToModel функции. Можно писать имена полей с вложеностью, типа name="post.meta.date"

? Другой вопрос интересный. При разработке больших приложений, часто необходимо управлять конфигурацией. Например: + для develop разрешить Source Maps + для stage разрешить логирование на специальный + иметь для разных сред (develop, stage, prod) разные внешние сервисы логирования, и токены для них + отключить какие-то features для develop, но включить их для prod + иметь разные пресеты конфигураций одного приложения для разных продуктов/клиентов + разные стили / логотипы / описания + разные наборы языков (например, когда новый язык ещё в разработке, он может быть в stage, но не в production) + поддерживать только определенные языки на develop Таких настроек может быть несколько десятков в крупном приложении. Часть из них могут быть доступны для переопределения через ENV. Кто как решает это? Какие практики и подходы есть в других экосистемах (Ruby, Elixir, Python и пр)?

? Другой вопрос интересный. При разработке больших приложений, часто необходимо управлять конфигурацией. Например: + для develop разрешить Source Maps + для stage разрешить логирование на специальный + иметь для разных сред (develop, stage, prod) разные внешние сервисы логирования, и токены для них + отключить какие-то features для develop, но включить их для prod + иметь разные пресеты конфигураций одного приложения для разных продуктов/клиентов + разные стили / логотипы / описания + разные наборы языков (например, когда новый язык ещё в разработке, он может быть в stage, но не в production) + поддерживать только определенные языки на develop Таких настроек может быть несколько десятков в крупном приложении. Часть из них могут быть доступны для переопределения через ENV. Кто как решает это? Какие практики и подходы есть в других экосистемах (Ruby, Elixir, Python и пр)?

"разрешить логирование на специальный"

? Другой вопрос интересный. При разработке больших приложений, часто необходимо управлять конфигурацией. Например: + для develop разрешить Source Maps + для stage разрешить логирование на специальный + иметь для разных сред (develop, stage, prod) разные внешние сервисы логирования, и токены для них + отключить какие-то features для develop, но включить их для prod + иметь разные пресеты конфигураций одного приложения для разных продуктов/клиентов + разные стили / логотипы / описания + разные наборы языков (например, когда новый язык ещё в разработке, он может быть в stage, но не в production) + поддерживать только определенные языки на develop Таких настроек может быть несколько десятков в крупном приложении. Часть из них могут быть доступны для переопределения через ENV. Кто как решает это? Какие практики и подходы есть в других экосистемах (Ruby, Elixir, Python и пр)?

У нас есть настройки по умолчанию и PRESET, который их переопределяет, т.е: 1. Сборка проекта: NODE_ENV=production PRESET=google-stage npm run build 1. Запуск проекта: NODE_ENV=production PRESET=google-stage npm run start Какие ещё интересные есть практики?

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

То есть вещи выходящие за логический смысл задавать их в том же .env

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

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

И насчет type='email' в статье - оно позволяет писать всякую фигню которая email'ом являться не может в принципе

И насчет type='email' в статье - оно позволяет писать всякую фигню которая email'ом являться не может в принципе

например? ;)

И насчет type='email' в статье - оно позволяет писать всякую фигню которая email'ом являться не может в принципе

Ты удивишься, насколько много разной фигни является валидным емейлом

Ты удивишься, насколько много разной фигни является валидным емейлом

+