Комментарии 27
Вообще-то круто. Как раз недавно волею судеб ковырял Google Sites — инструмент для совсем начинающих. Там даже скрипт вставить по нормальному не получается. Скрипт вставляется в песочницу iframe. А окно редактирования скрипта — маленький квадратик в центре экрана, который не получается расширить и без подсветки синтаксиса.
Здесь я так понял, предоставляются возможности визуального моделирования и при этом сохраняется полный контроль над кодом.
Здесь я так понял, предоставляются возможности визуального моделирования и при этом сохраняется полный контроль над кодом.
Привет, всё верно. В Quarkly можно писать код – свой компонент. В результате вы получаете виджет, который можно редактировать интерактивно.
Тут есть пример, как это сделать: www.youtube.com/watch?v=F0SS7xuI2ug
Тут есть пример, как это сделать: www.youtube.com/watch?v=F0SS7xuI2ug
Надо пробовать
Блин, столько громких слов, а смотрим набор блоков — инструмент для верстки лендинга.
Будем пробовать, тестить, давать фидбек =)
Классно, что используете Mobx.
Как я понимаю, визуального редактора логики нет и не планируется?
Написать скрипт с повторно используемой компонентами логикой (вроде Custom hook или HOC) и перетаскивать его в редакторе в любые компоненты тоже нельзя?
Как я понимаю, визуального редактора логики нет и не планируется?
Написать скрипт с повторно используемой компонентами логикой (вроде Custom hook или HOC) и перетаскивать его в редакторе в любые компоненты тоже нельзя?
С одной стороны — круто! Мне нравится, и хочу попробовать, побаловаться.
С другой стороны — а для кого? Не побаловаться, а прямо на полных щах использовать. Крупные проекты сразу отпадают хотя бы из за непростой поддержки. Малые проекты? Получается инструмент для создания интерактивных виджетов и подобных приколюх (и это не в негативной нотации, это тоже круто!), для каких либо веб-приложений. А ещё, думаю, для быстрого прототипирования.
С другой стороны — а для кого? Не побаловаться, а прямо на полных щах использовать. Крупные проекты сразу отпадают хотя бы из за непростой поддержки. Малые проекты? Получается инструмент для создания интерактивных виджетов и подобных приколюх (и это не в негативной нотации, это тоже круто!), для каких либо веб-приложений. А ещё, думаю, для быстрого прототипирования.
Спасибо за фидбек.
Мы идем от малого к большему. На данный момент мы тестируем проект: лендинги, блоги и простые приложения сейчас делать удобно. Наш сайт, документация (всё кроме самого конструктора) реализовано на Quarkly.
Также у нас есть пример небольшого приложения, которое сделал наш дизайнер: sad-easley-31c9dd.netlify.app
Мы идем от малого к большему. На данный момент мы тестируем проект: лендинги, блоги и простые приложения сейчас делать удобно. Наш сайт, документация (всё кроме самого конструктора) реализовано на Quarkly.
Также у нас есть пример небольшого приложения, которое сделал наш дизайнер: sad-easley-31c9dd.netlify.app
Как только вы в результате публикации проекта, созданного в вашем редакторе, научитесь выдавать проект без вашей обвязки в виде "@quarkly/components", "@quarkly/widgets" и т.д. — попробую, а до этого, извините — не хочу к себе в проект тащить ваш код
Не уверен, что это настолько критично, но вам видней.
И всё же, если посмотреть немножко на то, что они уже сделали — «Блог компании Quarkly», — то можно увидеть, что ребята нормально так Open Source'ят: "Как мы отказались от использования Styled-System для создания компонентов и изобрели собственный велосипед". Да и в статье есть отсылки, что много ещё чего в перспективе будет доступно в исходниках же )
Конечно, все мы знаем, что сам по себе NPM — та ещё свалка.
Но! Это же не мешает делать нормально )
А так избранная концепция критики, что, мол "@quarkly/components", "@quarkly/widgets" — это не комильфо, не содержит обоснований того, что конкретно не так…
То есть, иначе говоря: в чём ваша критика конструктивна? Просто негатив от того, что кто-то создал ещё один набор компонент для своих задач? Так может быть если бы другие наборы решали бы эти самые поставленные задачи, то не было бы необходимости делать ещё один? )
И всё же, если посмотреть немножко на то, что они уже сделали — «Блог компании Quarkly», — то можно увидеть, что ребята нормально так Open Source'ят: "Как мы отказались от использования Styled-System для создания компонентов и изобрели собственный велосипед". Да и в статье есть отсылки, что много ещё чего в перспективе будет доступно в исходниках же )
Конечно, все мы знаем, что сам по себе NPM — та ещё свалка.
Но! Это же не мешает делать нормально )
А так избранная концепция критики, что, мол "@quarkly/components", "@quarkly/widgets" — это не комильфо, не содержит обоснований того, что конкретно не так…
То есть, иначе говоря: в чём ваша критика конструктивна? Просто негатив от того, что кто-то создал ещё один набор компонент для своих задач? Так может быть если бы другие наборы решали бы эти самые поставленные задачи, то не было бы необходимости делать ещё один? )
"@quarkly/components", "@quarkly/widgets" — ок, если вы не видите в чем проблема таких пакетов, то я поясню. Проблема в том что они не дают значительной пользы по сравнению с базовыми тегами (которые и так все знают, а ваш инструмент нужно еще изучать). К тому же я молчу про то насколько КПД ваших компонентов мал, по 3-5 передаваемых проперти напрочь убивают смысл отдельных компонентов и просто создают шум — если хотите прокачать свои инструменты создайте больше специфичных компонентов (как критерий можете выбрать кол-во необходимых для передачи пропертей, попробуйте хотябы довести до 1-2). Сейчас вместо потока данных, я вижу только шум который создают ваши компоненты передавая немыслемое кол-во аргументов. В результате используя ваши «надстройки» мне нужно больше времени тратить на то чтобы понять как работает приложение (как организованы потоки данных). Чтобы хоть как-то использовать ваш «костыль» мне нужно нагородить своих высокоспецифичных оберток над ними, чтобы тупо скрыть весь этот ужас.
Поэтому я и написал, что лучше чтобы в результате публикации проект был представлен в виде базовых тегов с логикой на js, чем с вашими компонентами (так как все пропертя имеют константные значения — без проблем можно определить какой базовый тег там должен быть).
Поэтому я и написал, что лучше чтобы в результате публикации проект был представлен в виде базовых тегов с логикой на js, чем с вашими компонентами (так как все пропертя имеют константные значения — без проблем можно определить какой базовый тег там должен быть).
аналоги — github.com/artf/grapesjs, semantic-ui.com
semantic-ui.com Это библиотека UI элементов, не аналог
Круто, вы начали с того, что как раз не стоит делать на React — с лендингов и блогов.
хм, а как же Gatsby, Next.js?
если бы выбирали стек технологий под такие задачи — что бы Вы выбрали?
Svelte? или точечный кастом?
Лично мне хочется создать удобный инструмент, React — не самоцель
React мы выбрали по следующим причинам:
1. Популярен и много модулей, которые мы позволяем использовать в самой системе (через редактор кода компонента).
2. Лендинги и блоги все-таки люди создают — примеры выше, они как минимум популярны
3. React — самое удобное решение для разработки такого рода продукта: компоненты модульны, есть иструменты для сборки сайтов, есть hydrate, который тоже можно оптимизировать (монтировать только те ноды, которые видны, например)
И спасибо за комментарий, Вадим!
если бы выбирали стек технологий под такие задачи — что бы Вы выбрали?
Svelte? или точечный кастом?
Лично мне хочется создать удобный инструмент, React — не самоцель
React мы выбрали по следующим причинам:
1. Популярен и много модулей, которые мы позволяем использовать в самой системе (через редактор кода компонента).
2. Лендинги и блоги все-таки люди создают — примеры выше, они как минимум популярны
3. React — самое удобное решение для разработки такого рода продукта: компоненты модульны, есть иструменты для сборки сайтов, есть hydrate, который тоже можно оптимизировать (монтировать только те ноды, которые видны, например)
И спасибо за комментарий, Вадим!
Мне кажется, ценность инструмента несколько переоценена. Верстка не является чем-то запредельно сложным для фронтенд-разработчика. Попытки её автоматизировать имеют смысл для какого-нибудь агенства, для лендингов на потоке, когда фронтендеров мало или совсем нет в штате. Шаг в сторону с этого шоссе — и быстрее будет сделать интерфейс руками.
Переоценка — это здорово:) Правда, пока не очевидно кем и когда будет переоценено
Что же до «верстка это несложно». Конечно, все относительно и точно есть что посложнее, но есть одна простая идея: если на задачу можно потратить в 3 раза меньше времени, а речь идет задачах на часы, но это выигранные человекодни. А задач по верстке(кваркли решает не только их, но раз уж мы о них) в этом мире очень много.
Так что, тот факт, что кому-то это сэкономит время и значительно без потери качества — по-моему это добро.
Что же до «верстка это несложно». Конечно, все относительно и точно есть что посложнее, но есть одна простая идея: если на задачу можно потратить в 3 раза меньше времени, а речь идет задачах на часы, но это выигранные человекодни. А задач по верстке(кваркли решает не только их, но раз уж мы о них) в этом мире очень много.
Так что, тот факт, что кому-то это сэкономит время и значительно без потери качества — по-моему это добро.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Представляем Quarkly – инструмент для react-разработчиков и дизайнеров, который поможет оптимизировать вашу разработку