Офигеть! Я давно хотел узнать что за дерево растёт рядом, после прочтения о запросе «ленивой кошки из монголии» попробовал «дерево с боль» и выдало "… шими листьями и длинными стручками" и это было именно то дерево! :)
Так GraphQL — это как раз для тех случаев, когда уже понадобилось. Facebook его делал для унификации своего API между web-клиентом и мобильными клиентами.
А потом еще один и еще один. И закончим с 20 endpoint'ами для вытаскивания одной и той же сущности с разным набором полей.GraphQL это скорее не о фильтрации данных, а о том, чтобы одним и тем же endpoint'ом вытаскивать разные наборы полей для данного конкретного фильтрованного запроса.
Это как раз изобретение своего собственного DSL аналогичного graphql. Прямо сейчас это список полей, потом понадобятся вложенные сущности и, в итоге, родится что-то похожее.
Угу. Даже когда надо бы обновить, они не будут. Т.к. Angular следит за изменениями через shallowCompare. Как только у нас массив или объект с свойствами, здравствуй закат солнца вручную через ngDoCheck, причём её надо выполнять очень быстро, т.к. она будет вызываться при абсолютно любом событии и много раз за цикл rerender. А раз у нас всё вручную, то можно и забыть случайно обновить. Типа вот так https://github.com/primefaces/primeng/pull/986/
Я согласен, в таких вырожденных случаях React.createElement будет, наверное, удобнее даже визуально. Но, когда это обычный html с минимумом кода, то jsx всё-таки приятнее.
Опять же, в примере с React я тут вижу просто компоненту, у которой атрибуты тоже компоненты. На самом деле
<A>
<B/>
</A>
эквивалентно
<A children={<B/>} />
ну или
<A children={[<B/>]} />
т.к. в children могут быть несколько элементов.
И это ОЧЕНЬ удобно.
Есть еще вариант, например, как сделано в react-bootstrap модальное окно.
<div className="static-modal">
<Modal.Dialog>
<Modal.Header>
<Modal.Title>Modal title</Modal.Title>
</Modal.Header>
<Modal.Body>
One fine body...
</Modal.Body>
<Modal.Footer>
<Button>Close</Button>
<Button bsStyle="primary">Save changes</Button>
</Modal.Footer>
</Modal.Dialog>
</div>
Все эти Header, Footer, Dialog, это статические поля в классе Modal.
В методе Modal.render потом вручную фильтруются дети. Что-то наподобие const header = this.props.children.filter(child=> child.type === Modal.Header)
На самом деле, <template>, который браузер отпарсит в DOM, а мы потом размножим и удалим шаблон, будет намного медленней. Это была одна из проблем Angular 1, которую Angular 2 решает с помощью AoT компиляции шаблонов. Весь смысл Virtual DOM в том, что браузер очень медленно работает с DOM деревом, поэтому нужны костыли. http://stackoverflow.com/questions/28857074/angular-compile-is-slow-how-to-avoid
Там использован development build React'а с проверками и варнингами. Причём только реакта, остальные библиотеки там минифицированные. Интересно, это ошибка или попытка смухлевать?..
Это PrimeNG https://github.com/primefaces/primeng/tree/master/components/datatable/datatable.ts. Уже больше тысячи коммитов, я не думаю, что автор не разбирается в A2.
А вся эта возня с change detection в ngDoCheck? A2 же делает shallow compare, так что как только у нас компонент хочет на вход массив, приехали, делаем ручками проверку let changes = this.differ.diff(this.value); if(changes) {....}. А внутри у нас три списка added, removed, changed. По-мне так «А давайте просто перерисуем всё заново» c вкраплениями shouldComponentUpdate при необходимости, гораздо приятнее. А, да, и change detection у нас запускается еще чаще чем в A1, теперь и на каждый mouse move. Т.к. мы перехватываем через zone.js абсолютно все события браузера.
В React варианте там очень элегантно сделали render элементов списка. Просто автокомплиту передаётся параметр renderItem, который является функцией, которая возвращает разметку для элемента. По-моему гораздо лучше и очевидней чем <template>.
А все эти тонкости когда у нас иногда [propertyName]=«propertyValue», а иногда [attr.propertyName]=«propertyValue»?
А фишки типа <p-column [field]=«myprop»/> когда myprop=«my.cool.id.with.dots» и это всё ломает, т.к. field-то строка, а компонент-то хочет сделать из неё путь до property какого-то вложенного объекта потому что нельзя передать туда функцию getter? Не уверен, что нельзя, скорее всего можно, но так никто не делает — не принято.
Это то, с чем я столкнулся буквально за первые пару недель копания с Angular 2 т.к. компания выбрала его, а не React, как раз из-за «ну это же framework, это же от Google!»
Тут где-то 80% кода можно переиспользовать в обоих ветках, когда есть headerRows и когда нет. Если бы это был JSX, то можно было бы разбить этот шаблон на мелкие куски, положить их в переменные а потом собрать из них нужное.
т.к. headerTemplate у нас просто функция, которая возвращает разметку. Самая вкусная фишка JSX, в том, что это просто какой-то JSON объект, который можно положить в переменную, вернуть как результат вызова функции и т.д. Аналог ангуляровского <template>....</template> в react это просто React.cloneElement(myVariable,...)
https://github.com/primefaces/primeng/blob/master/components/autocomplete/autocomplete.ts
vs
https://github.com/reactjs/react-autocomplete/blob/master/lib/Autocomplete.js
Неужели вот этот дикий шаблон в a2 правда лучше того, что в react?
1 и 2 делаются через spread operator, он уже stage2 вроде бы.
Третье:
var Element = isVisible? <div/>: <span/>
<Element .....>
Вполне сработает. Тут другой подводный камень:
var b = false
Выведет
а не
как можно было предположить. Так сделано именно для того, чтобы можно было писать {b && <div/>}
Последний пример, теоретически, можно сделать как
React = new BemDomFactory('my-list');
и потом
<div ...../>
эквивалентно
ну или
т.к. в children могут быть несколько элементов.
И это ОЧЕНЬ удобно.
Есть еще вариант, например, как сделано в react-bootstrap модальное окно.
Все эти Header, Footer, Dialog, это статические поля в классе Modal.
В методе Modal.render потом вручную фильтруются дети. Что-то наподобие const header = this.props.children.filter(child=> child.type === Modal.Header)
А вся эта возня с change detection в ngDoCheck? A2 же делает shallow compare, так что как только у нас компонент хочет на вход массив, приехали, делаем ручками проверку let changes = this.differ.diff(this.value); if(changes) {....}. А внутри у нас три списка added, removed, changed. По-мне так «А давайте просто перерисуем всё заново» c вкраплениями shouldComponentUpdate при необходимости, гораздо приятнее. А, да, и change detection у нас запускается еще чаще чем в A1, теперь и на каждый mouse move. Т.к. мы перехватываем через zone.js абсолютно все события браузера.
Простите, накипело :)
А все эти тонкости когда у нас иногда [propertyName]=«propertyValue», а иногда [attr.propertyName]=«propertyValue»?
А фишки типа <p-column [field]=«myprop»/> когда myprop=«my.cool.id.with.dots» и это всё ломает, т.к. field-то строка, а компонент-то хочет сделать из неё путь до property какого-то вложенного объекта потому что нельзя передать туда функцию getter? Не уверен, что нельзя, скорее всего можно, но так никто не делает — не принято.
Это то, с чем я столкнулся буквально за первые пару недель копания с Angular 2 т.к. компания выбрала его, а не React, как раз из-за «ну это же framework, это же от Google!»
Тут где-то 80% кода можно переиспользовать в обоих ветках, когда есть headerRows и когда нет. Если бы это был JSX, то можно было бы разбить этот шаблон на мелкие куски, положить их в переменные а потом собрать из них нужное.
заменяется на что-то вроде:
т.к. headerTemplate у нас просто функция, которая возвращает разметку. Самая вкусная фишка JSX, в том, что это просто какой-то JSON объект, который можно положить в переменную, вернуть как результат вызова функции и т.д. Аналог ангуляровского <template>....</template> в react это просто React.cloneElement(myVariable,...)
vs
https://github.com/reactjs/react-autocomplete/blob/master/lib/Autocomplete.js
Неужели вот этот дикий шаблон в a2 правда лучше того, что в react?