jade может быть неплох если ты верстальщик на фрилансе и работаешь один и быстро, так как давно на нем пишешь. но пихать в реакт, зачем?

jade же просто лекарство от скобочной болезни

Я как к джейду богоподобному прикоснулся понял что лицезрел господа

Не, меня интересует экспиэренс. Есть ли там что-то такое, что прямо вот надо пробовать?

Те же яйца, только с боку, ну и обсерверы из коробки. Как по мне самый большой минус vue - это скупость готовых компонентов, и ui. То есть если делать стартап, то наверное реакт + toolbox, порог вхождения ниже и куча коробочных решений

Те же яйца, только с боку, ну и обсерверы из коробки. Как по мне самый большой минус vue - это скупость готовых компонентов, и ui. То есть если делать стартап, то наверное реакт + toolbox, порог вхождения ниже и куча коробочных решений

Спасибо!

Те же яйца, только с боку, ну и обсерверы из коробки. Как по мне самый большой минус vue - это скупость готовых компонентов, и ui. То есть если делать стартап, то наверное реакт + toolbox, порог вхождения ниже и куча коробочных решений

Мне DX не нравится у них.

Селекторы, темплейты

Я как к джейду богоподобному прикоснулся понял что лицезрел господа

Любой язык хорош, если писать код красиво.

Даже XML в react

Любой язык хорош, если писать код красиво.

Красота страшная сила

Но как по мне, весь этот табозависимый сахар нефига не удобен. И если его и юзать, то только в закромах своих проектов

Но как по мне, весь этот табозависимый сахар нефига не удобен. И если его и юзать, то только в закромах своих проектов

Там пробелы можно юзать:) но вы щас как бы и на питон тоже батон крошите:) насчет удобности

Не придирайся. Ты точно понял, что я имел ввиду

А питон тоже туда же, кстати))

Селекторы, темплейты

все хрень(у них изначально цель была сделать реакт для тех у кого бомбит от реакта), но теперь там есть jsx и stateless functions

По факту да. Но опять таки такие аспекты носят исключительно субьективный характер

все хрень(у них изначально цель была сделать реакт для тех у кого бомбит от реакта), но теперь там есть jsx и stateless functions

Ох ё

И врятли могут быть серьезными аргументами

И врятли могут быть серьезными аргументами

ну это мы предлагаем отступать от канона, с нас и аргументы. но имхо смысла нет, не стоит рекламировать героин.

И врятли могут быть серьезными аргументами

Так херня то в том, что я никому не навязываю свое мнение и если мне нравится какой то синтаксис, то я юзаю его тихо, так как тут реакт-сообщество и большинство пишет на XML в рендере

Вот насчёт очевидности jade я даже не знаю — в связке с реактом много совсем не очевидных моментов

Вот насчёт очевидности jade я даже не знаю — в связке с реактом много совсем не очевидных моментов

Например?

ну это мы предлагаем отступать от канона, с нас и аргументы. но имхо смысла нет, не стоит рекламировать героин.

не могу насмотреться на твою авку

за душу берет

Например?

Ну например то, как он будет переваривать переносы строки внутри { }, как будет отличать данные от тегов

Он так то насколько я помню изи {} переваривает

Ну по крайней мере сколько я на нем писал

Ладно завтра буду бодаться

за душу берет

ведущие меметологи одобряют ;)

Вообще, можно рендер писать в json. Очень весело и не надо париться о табуляции

Он так то насколько я помню изи {} переваривает

<div>{data.map(e=>e?<Component />:<span>null</span>)}</div> По моему поперхнется, особенно если это сейчас нормально отформатировать

как же бесит что у всех свое чувство прекрасного кода...

как же бесит что у всех свое чувство прекрасного кода...

А кому то чуждо все прекрасное и вообще работает и ладно

<div>{data.map(e=>e?<Component />:<span>null</span>)}</div> По моему поперхнется, особенно если это сейчас нормально отформатировать

Не точно не похерится

Вообще, можно рендер писать в json. Очень весело и не надо париться о табуляции

Это был немножко троллинг

Но все завтра

Вообще, можно рендер писать в json. Очень весело и не надо париться о табуляции

Я думаю за этим будующее без шуток

закрывающие теги нужны только для машины

XML наше все. Привычные теги. Привычная работа с { }

Да даже /> уже приелось

XML это зло)) Как формат

Это да

xslt кстати тоже зло

И его никто не планирует юзать в реакте надеюсь?))

Он — зло в квадрате

Хотя в реакте он был бы на самом деле очень даже ок

Потому что порой обычного XML не хватает

Зачем?

Ну например много было бы из коробки не используя лодаш или обычный жс для элементарных вещей

Особенно если xslt взять ?

И вообще программы целиком на нём делать

> PureComponent первый раз слышу, это что такое, насколь эффективно использовать? типа свойств недостаточно?

И во что бы это компилировалось?

"Пока в психушку не заберут, конечно"

> PureComponent первый раз слышу, это что такое, насколь эффективно использовать? типа свойств недостаточно?

Если я не ошибаюсь оно нужно для компонентов без состояния

Но практического применения до сих пор нет. Только на уровне документации

Либо я кривожоп и оно у меня не работает

И во что бы это компилировалось?

Как обычно же

Но практического применения до сих пор нет. Только на уровне документации

так на npm вроде есть что-то

"Пока в психушку не заберут, конечно"

Ну, было пару проектов на чистом xslt, да по первому времени стреляешь себе во что только можно, но потом приходит понимание

Ну, было пару проектов на чистом xslt, да по первому времени стреляешь себе во что только можно, но потом приходит понимание

Пару?! То есть первого было не достаточно? ?

так на npm вроде есть что-то

О_о.

Пару?! То есть первого было не достаточно? ?

А то

О_о.

https://www.npmjs.com/package/pure-component не оно?

https://facebook.github.io/react/docs/react-component.html

тут нифига тоже нет :C

https://facebook.github.io/react/docs/react-component.html#shouldcomponentupdate

последний абзац

о увидела, спасибо

С выходом 15.0 был раздел в референс: React.PureComponent

Сечас чо та нету

да он не нужен

его выпилят

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

там проблемы с обновлением пропсов

ишью были про это

хотя может и доки допилят, но все равно это ненужная фигня

Нафига тогда добавлять было, что бы потом выпилить.

потому что это фб

Ну бред же. Короче ждем файбер. Там должно быть интересно

всегда так делают

там ничего не поменяется

в высокоуровневом апи

Массивы в рендере

Долой лишние DIV

ну это да

а так первое время из плюсов больше ничего

потом на этом можно будет много интересного придумать уже. но это потом

В любом случае осталось ждать не так долго. Уже больше половины пасснули http://isfiberreadyyet.com

Подскажите, как лучше организовать структуру store. У меня есть такие сущности: { playlist: { stream: {...}, videos: [{...}, {...}, {...}] }} И всё это Immutable.js То есть плейлист состоит из одного стрима и нескольких видео. Объекты стрима и видео по структуре условно одинаковые. Мне нужно знать, какой объект сейчас выбран. В каком виде лучше хранить это? Какие варианты вижу я: 1. Рядом хранить копию выбранного объекта и обращаться к ней. Типа: { playlist: {...}, selected_video_or_stream: {...} } Я на нём и остановился. Всё было круто до момента, когда помимо чтения объекта понадобилась ещё и запись в него. Нужно или каким-то образом синхронизировать копию с оригиналом или переходить к другим вариантам. 2. Хранить индекс объекта. { playlist: {...}, selected_video_or_stream: 15, } Будет особый случай для индекса стрима. Типа if (selected_video_or_stream == 'stream') ... Немного некрасиво, но терпимо. Чтение будет менее удобным, но отпадает нужда в синхронизации. Сейчас этот вариант кажется самым правильным и к нему и склоняюсь. 3. В самом выбранном объекте хранить boolean selected. {playlist: { stream: {...}, videos: [ {...}, {...}, {..., selected: true, }, {...}] }} Но этот кажется вообще неудобным. Может есть какие-то best practice по подобному случаю? Подскажите.

Народ у меня вопрос. Нормально ли будет если Компонент будет обращаться к какому либо кастомному методу в Store для получения к примеру Id выделенного элемента? (метод просто возвращает значение)

т.е. в Store есть же метод getState а если еще там будет метод getSelectedId нормально ли это будет.

Вообще конечно это можно вынести и устанавливать значение в Контейнере через спец свойство у табличного компонента

наверное так лучше будет, также?

Контейнерный компонент имеет же метод calculateState бла бла

Подскажите, как лучше организовать структуру store. У меня есть такие сущности: { playlist: { stream: {...}, videos: [{...}, {...}, {...}] }} И всё это Immutable.js То есть плейлист состоит из одного стрима и нескольких видео. Объекты стрима и видео по структуре условно одинаковые. Мне нужно знать, какой объект сейчас выбран. В каком виде лучше хранить это? Какие варианты вижу я: 1. Рядом хранить копию выбранного объекта и обращаться к ней. Типа: { playlist: {...}, selected_video_or_stream: {...} } Я на нём и остановился. Всё было круто до момента, когда помимо чтения объекта понадобилась ещё и запись в него. Нужно или каким-то образом синхронизировать копию с оригиналом или переходить к другим вариантам. 2. Хранить индекс объекта. { playlist: {...}, selected_video_or_stream: 15, } Будет особый случай для индекса стрима. Типа if (selected_video_or_stream == 'stream') ... Немного некрасиво, но терпимо. Чтение будет менее удобным, но отпадает нужда в синхронизации. Сейчас этот вариант кажется самым правильным и к нему и склоняюсь. 3. В самом выбранном объекте хранить boolean selected. {playlist: { stream: {...}, videos: [ {...}, {...}, {..., selected: true, }, {...}] }} Но этот кажется вообще неудобным. Может есть какие-то best practice по подобному случаю? Подскажите.

Норм с индексом, некрасивость из-за некрасивой структуры.

Норм с индексом, некрасивость из-за некрасивой структуры.

Понял. Спасибо.