Я всегда задавался следующим вопросом, валидно ли мы делаем SPA? Суть вопроса в том, что всю семантику мы включаем в <div/>, ведь вариантов у нас немного?
Т.е. получается так:
всех кейсов не покрыть, я тоже немного размыто написал, речь не про виджеты, а скорее про блок на всю ширину страницы, с виджетами такой вариант вряд ли подойдёт
вообще мой основной посыл был в том, что можно жить без жёстко заданных брейкпоинтов, а вообще лучше исходить из здравого смысла, бутстрап не серебряная пуля
всё верно, вёрстка сайта – это не вёрстка газеты, верстать в pixel perfect, как в парадигме — не имеет смысла, но сам инструмент наложения скринов макета на свёрстаную страницу весьма полезен и я его рекомендую к использованию, что бы видеть явные расхождения и дизайнер был в курсе.
Как правило, дизайнеры очень дорожат вертикальными отступами, потому что у всех страниц есть ритм который нарушать нельзя. В любой дизайн системе вертикальные отступы обычно кратны определённой величине.
согласен, это было бы идеально, на моей памяти у меня был только один такой дизайнер, с ним круто было работать.
я постарался вынести самое основное в блок «Что следует знать дизайнерам о фронтенде»
на счет pixel perfect, я не писал, что нужно верстать всё один-в-один, но явные отличия знать стоит, я воспринимаю pixel perfect как инструмент, а не как парадигму
Всегда пожалуйста, вам тоже спасибо за комментарий и прошу прощения, что долго не отвечал.
Это сделано для больше для удобства, в целом, можно передать начальные значения и во Wrapper, а потом перед возвращением нового класса обработать эти значения и передать в конструктор. Кроме удобства это делается для разделения ответственности, как правило HOC получает только компонент и возвращает компонент, а вся логика обработки дополнительных значений вынесена на уровень выше, например, если посмотреть тот же connect из react-redux, он реализован примерно также. Кроме этого, на официальном сайте говорится, что такой паттерн предпочтительней https://reactjs.org/docs/higher-order-components.html
спасибо за комментарий, согласен с вами, но я читал статью, в которой говорилось, что в вашем кастомном компоненте надо стараться предусмотреть возможность передать все html атрибуты, которые могут понадобиться, поэтому id я посчитал важным и передал. В целом, его можно не заполнять
спасибо за комментарий, я эту тему уже развиваю, но здесь всё не поместилось.
На одном из проектов мне приходило от сервера описание формы в виде массива с объектами, в которых были тип каждого инпута, атрибуты и прочее. Надо было слать предварительный запрос для создания формы, а потом из полученных данных её собирать. Я постараюсь написать об этом следующую статью.
Спасибо за комментарий, о react-final-form не слышал ранее, обязательно посмотрю, а Formik знаю, даже успел пощупать его, удобная библиотека, у меня в закладках. Но основная цель статьи была показать, как можно использовать концепцию HOC на примере формы.
Забудьте про div, семантика спасёт интернет
Я всегда задавался следующим вопросом, валидно ли мы делаем SPA? Суть вопроса в том, что всю семантику мы включаем в <div/>, ведь вариантов у нас немного?
Т.е. получается так:
Боль фронтов, или что нам нужно от дизайнеров
пример с кнопками отличный
Боль фронтов, или что нам нужно от дизайнеров
Боль фронтов, или что нам нужно от дизайнеров
вообще мой основной посыл был в том, что можно жить без жёстко заданных брейкпоинтов, а вообще лучше исходить из здравого смысла, бутстрап не серебряная пуля
Боль фронтов, или что нам нужно от дизайнеров
Боль фронтов, или что нам нужно от дизайнеров
Боль фронтов, или что нам нужно от дизайнеров
Боль фронтов, или что нам нужно от дизайнеров
Боль фронтов, или что нам нужно от дизайнеров
Как правило, дизайнеры очень дорожат вертикальными отступами, потому что у всех страниц есть ритм который нарушать нельзя. В любой дизайн системе вертикальные отступы обычно кратны определённой величине.
Боль фронтов, или что нам нужно от дизайнеров
основы работы figma точно знать стоит
Боль фронтов, или что нам нужно от дизайнеров
я постарался вынести самое основное в блок «Что следует знать дизайнерам о фронтенде»
на счет pixel perfect, я не писал, что нужно верстать всё один-в-один, но явные отличия знать стоит, я воспринимаю pixel perfect как инструмент, а не как парадигму
Работа с формами в React.js, используя базовый инструментарий
Это сделано для больше для удобства, в целом, можно передать начальные значения и во Wrapper, а потом перед возвращением нового класса обработать эти значения и передать в конструктор. Кроме удобства это делается для разделения ответственности, как правило HOC получает только компонент и возвращает компонент, а вся логика обработки дополнительных значений вынесена на уровень выше, например, если посмотреть тот же connect из react-redux, он реализован примерно также. Кроме этого, на официальном сайте говорится, что такой паттерн предпочтительней
https://reactjs.org/docs/higher-order-components.html
Работа с формами в React.js, используя базовый инструментарий
Работа с формами в React.js, используя базовый инструментарий
Работа с формами в React.js, используя базовый инструментарий
Работа с формами в React.js, используя базовый инструментарий
На одном из проектов мне приходило от сервера описание формы в виде массива с объектами, в которых были тип каждого инпута, атрибуты и прочее. Надо было слать предварительный запрос для создания формы, а потом из полученных данных её собирать. Я постараюсь написать об этом следующую статью.
Работа с формами в React.js, используя базовый инструментарий