Сколько лет они уже появляются, так и не появились

ну раньше было компонентами делали UI/UX десктопных приложений. Кинул button на форму, прописал события для кнопки. Скомпилил и все заработало.

сейчас есть web components, polimer короче с реактом потихоньку это все возвращается

концепция основанная на loosely coupled components.

отсюда же пошли тенденции inlinecss и прочего

Ну, полюбому, придется пройти все то же, что проходил и десктоп, но я надеюсь браузер не остановится там же MVVM... буэ

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

Ребята отправил PR в реакт https://github.com/facebook/react/pull/7853 поставьте пальчик )

??

Не вижу плюсов от виз. редактора на вебе. У нас и так достаточно короткий цикл обратной связи (а с хотрелоадом вообще до смешного маленький).

Тут тебе не надо ждать минуту пока скомпилится чтобы поглядеть как там у тебя кнопка стоит, например

Поменял, тут же увидел и, если надо, подправил

ну хотя с другой стороны бэкенд тоже не отстает. по мере развития проекта стэк имеет тенденцию рости ну хотя бы как es, logstash, kibana всякие graphena, это еще как-то администрировать нужно.

больше девопс растёт последнее время

нежели непосредственно бэкэнд

Тут тебе не надо ждать минуту пока скомпилится чтобы поглядеть как там у тебя кнопка стоит, например

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

зачем визуальный редактор? стандарты определенные нужны на UI/UX чтобы ты могу легко интегрировать компоненты которые кто-то еще написал в свое приложение особо не тратя время на разбор того что там внутри.

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

А? )

Я поясню зачем нужен graphql

https://www.polymer-project.org/1.0/

кто нибудь юзал?

зачем визуальный редактор? стандарты определенные нужны на UI/UX чтобы ты могу легко интегрировать компоненты которые кто-то еще написал в свое приложение особо не тратя время на разбор того что там внутри.

Посмотрим, но мне кажется, что такие инструменты быстро дохнут. Есть же всякие Macaw, по их поводу не вижу ажиотажа. Просто на десктопе это реально сложно было смотреть/держать в голове, а на фронте к этому все привыкли и про feedback loop я уже сказал выше. Т.е. проблема просто по-другому решена. А наговнякать по-быстрому и сейчас можно много на чем.

GraphQL нужен затем что бэк превращается в ожерелье микросервисов разной степени абстракции. И это правильно. Чем дальше в лес тем больше будет унифицированных микросервисов которые будут выполнять стандартные задачи + микросервисы под локальные задачи проекта. Вся остальная бизнес-логика и сценарии уйдут на фронт целиком. Для того чтобы обеспечить эти толстые клиенты данными нужен единый API gateway для каждого конкретного проекта чтобы не охренеть от запросов и не ддосить сервера без кэша

у меня щаз ожерелье такое

зачем всю логику на фронт кидать?

переношу сейчас на Kubernetes кластер потихоньку т.к. devops через ssh/ansible стал жрать слишком много времени времени.

логика уже по факту на фронте

Ansible совсем не айс?

айс

Про Kubernetes гоу сюда @kubernetes_ru :)

но все равно. задач то меньше не становится.

о вот это круто. я как бы только начал еще не все понимаю нормально.

ищу фронт либу для динамоческой формы-фильтра а-ля яндекс маркет на основе "схемы" (вопрос не про jquery и не делать всё ручками)

ищу фронт либу для динамоческой формы-фильтра а-ля яндекс маркет на основе "схемы" (вопрос не про jquery и не делать всё ручками)

уже второй день ищешь

да

мб в гугле и на стековерфлоу будет быстрее

такого безобразия на бэке нет )

https://community.algolia.com/instantsearch.js/examples/media/ такое пойдет?

мб в гугле и на стековерфлоу будет быстрее

уже

но поверхностно. я прост не фронт с кухней не знаком

всё на гитхабе посмотрел но то же очевидное решение

мож слова не те пользую

http://www.searchkit.co

глянь

фронтенд для elastisearch

вот другой пример, https://community.algolia.com/instantsearch.js/examples/e-commerce/

фронтенд для elastisearch

о спаибо люблю эластику

вот другой пример, https://community.algolia.com/instantsearch.js/examples/e-commerce/

спасибо, но концепция не та у меня "одноуровневый" но с кучей фильтр полей(яндекс маркет)

тебе наружу нужно или для внутреннего пользования?

наружу

пока бэк пилю

python?

похапе

наружу для эластика есть бинды к angularjs, а для reactjs есть searchkit.

на имхонете шикарный фильтр.. эххх

мне для внутреннего нужно было поэтому я просто взял kibana и выкинул свой дашборд.

наружу для эластика есть бинды к angularjs, а для reactjs есть searchkit.

спасибо гляну. у меня как раз эластика

у меня нет требований по дизайну. я делаю "прототип"

должны позволять, на searchkit Apache License 2.0

на кибана тоже

я прост не в теме про кибану как её закастомить под имеющуюююся структуру

никак наверное

проще написать свое лол

https://github.com/elastic/kibana/blob/master/Gruntfile.js

хотя не

можно запарится

наверное сделать кастомный билд со своим css

но я бы не стал.

друзья, а как получить attribute у dom ноды в enzyme?

Смотрите, человек пишет тесты для реакта)

Это типа с уважением сказано

я пишу =(

везде

@Havenchyk В реакте нет аттрибутов у дом нод. Есть пропсы

Здарова, мужики.

@esseswann спасибо за разъяснение. остановился на mount(<Component />).find('img').node.src

Тут не только мужики

Да, так норм

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

Получай через js объект короче

@istinspring Совершенно верно. Если ты пишешь тесты постфактум ты ещё и жалаеешь себя и подсознательно подстраиваешь их под косяки в коде

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

ну правда я юниты только пишу

есть еще всякие e2e

Есть здесь кто-нибудь понимающий магию babel?

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

а какая магия в babel?

Есть здесь кто-нибудь понимающий магию babel?

http://babeljs.io/repl/#?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-2&code=

а какая магия в babel?

человек 10 знают как он работает полностью и понимают каждый плагин) мб даже меньше))

:) все уже в FB?

друзья, подскажите, пожалуйста, как проекты уровня react генерируют changelog

а дайте ссылки на хантерские чаты по ноде.

http://ruby-hyperloop.io

пожалуйста