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