// enable runtime transpilation to use ES6/7 in node var fs = require('fs') var babelrc = fs.readFileSync('./.babelrc') var config try { config = JSON.parse(babelrc) } catch (err) { console.error('==> ERROR: Error parsing your .babelrc.') console.error(err) } require('babel-register')(config)

я так запускаю ноду

нахуя?

реакт и экспресс в одной репе. react лежит в ./client. лучше отдельный package.json и node_modules для папки с реактом или общий, в корне репы?

реакт и экспресс в одной репе. react лежит в ./client. лучше отдельный package.json и node_modules для папки с реактом или общий, в корне репы?

Наверное отдельный, тогдк будет проще разделить если надо

подскажите, есть такой код, почему this.props.onLoad выполняется сразу же, не дожидаясь резолва?

потому что там нет промисов?)

хм, об этом не подумал чет, щас чекну еще раз

хм, об этом не подумал чет, щас чекну еще раз

При первом рендере там и правда не должно быть промисов

При первом рендере там и правда не должно быть промисов

setTimeout 0 помогло)

мэээ

А ещё не могу понять такое странное объявление класса и рендер в виде стрелочной функции

setTimeout 0 помогло)

Костыли костылями погоняют?)

Костыли костылями погоняют?)

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

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

А почему тогда просто глобальную функцию не сделать?

А почему тогда просто глобальную функцию не сделать?

так нельзя, она должна быть уникальна на каждое соединение

Подскажите, как получить DOMNode getElementBy внутри класса React? https://reactjs.org/docs/portals.html тут они делают это вне класса, попытавшись перенести в класс просто как el = document.getElem... получил undefined. Может, в каком-то lifecycle методе вызывать?

Подскажите, как получить DOMNode getElementBy внутри класса React? https://reactjs.org/docs/portals.html тут они делают это вне класса, попытавшись перенести в класс просто как el = document.getElem... получил undefined. Может, в каком-то lifecycle методе вызывать?

Ref

Ref

? ref это же про react DOM node . А мне нужна нода из статического html файла, куда я буду рендерить реакт приложение. Возможно, я не понял, более подробный ответ будет очень кстати.

? ref это же про react DOM node . А мне нужна нода из статического html файла, куда я буду рендерить реакт приложение. Возможно, я не понял, более подробный ответ будет очень кстати.

Ну так просто const el = document.getElementById(‘root’)

Ну так просто const el = document.getElementById(‘root’)

внутри класса хочу сделать. Снаружи всё работает.

внутри класса хочу сделать. Снаружи всё работает.

Тогда на componetDidMount

Тогда на componetDidMount

спасибо, попробую.

Просто что ты собрался туда рендерить из класса

Подскажите, как получить DOMNode getElementBy внутри класса React? https://reactjs.org/docs/portals.html тут они делают это вне класса, попытавшись перенести в класс просто как el = document.getElem... получил undefined. Может, в каком-то lifecycle методе вызывать?

всё оказалось проще, я просто перенес element внутрь класса, и продолжил ссылаться на него, как на element, а не как на this.elment, логично получая undefined. Всё нормально работает внутри класса.

http://react-file-structure.surge.sh/

Уважаемые, подскажите, каким образом фиксируется шапка сайта при скроллинге, уже несколько дней хочу определить это но чет пока никак не дойдут руки до реакта есть предположение что у реакта есть событие скролинга и при скроле > 0 меняются стили и шапка фиксируется, это так или я ошибаюсь и для такой задачи юзаются всякие джеквери-хуери ?

google -> position: fixed / position: sticky

google -> position: fixed / position: sticky

ммм, да это понятно

Вопрос был не в этом

google -> position: fixed / position: sticky

Ты меня аж расстроил

всм расстроил

по описанию это как раз то

Уважаемые, подскажите, каким образом фиксируется шапка сайта при скроллинге, уже несколько дней хочу определить это но чет пока никак не дойдут руки до реакта есть предположение что у реакта есть событие скролинга и при скроле > 0 меняются стили и шапка фиксируется, это так или я ошибаюсь и для такой задачи юзаются всякие джеквери-хуери ?

Фиксированная позиция в начале, при скролле на сколько там тебе надо — сброс позиционирования и отображение в соответствии с разметкой. Если я правильно поняла что ты хочешь

Фиксированная позиция в начале, при скролле на сколько там тебе надо — сброс позиционирования и отображение в соответствии с разметкой. Если я правильно поняла что ты хочешь

Наоборот, изначально позиция relative к примеру, после прокрутки на 10px позиция меняется на fixed left0 top0

Наоборот, изначально позиция relative к примеру, после прокрутки на 10px позиция меняется на fixed left0 top0

Ну значит наоборот делай. В любом случае тебе нужно следить за скроллом.

Да вообщем, для меня уже очевидно как это работает, спасибо за ответы

Доскроллил до точки @ отпустил хедер в свободное прилипалово

@ хедер улетел прилипать на марс

@ хедер улетел прилипать на марс

@ Как тебе такое Илон Маск

Привет всем В ближайшем будущем возможно понадобится пилить PWA, что лучше использовать? Ionic? React? React-Ionic?

Народ, а есть дока о том, что тестировать в компонентах? Что-то вроде памятки, например: 1. не забудьте проверить каждый props и его возможные значения 2. проверьте у формы валидацию и сабмит 3. ...

Я так понимаю, что Ionic хорошо для тех, кто хочет задеплоить не только в mobile web, но так-же в store app/andrd И еще много всего UPD: Вроде понял разницу, Ionic - Angular, React - React lol ?

Народ, а есть дока о том, что тестировать в компонентах? Что-то вроде памятки, например: 1. не забудьте проверить каждый props и его возможные значения 2. проверьте у формы валидацию и сабмит 3. ...

3. вызов функции в cdm 4. изменение стейта (например, ченжи в форме) 5. снапшот p.s. вопрос хороший, тоже интересно p.p.s. тут есть материал по теме - https://maxpfrontend.ru/vebinary/testirovanie-komponentov-s-pomoschyu-jest-enzyme/

Народ, а есть дока о том, что тестировать в компонентах? Что-то вроде памятки, например: 1. не забудьте проверить каждый props и его возможные значения 2. проверьте у формы валидацию и сабмит 3. ...

Ничего. Достаточно просто типизировать.

Ничего. Достаточно просто типизировать.

Придти к бизнесу и сказать давайте переделаем с типизацией N* проектов?

Придти к бизнесу и сказать давайте переделаем с типизацией N* проектов?

Да, если стремиться к качеству, то все равно это придется делать. Делайте постепенно.

Да, если стремиться к качеству, то все равно это придется делать. Делайте постепенно.

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

Тестировать компоненты бесмысленно. Тестируйте логику.

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

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

Если проект нетипизирован, то он не написан отлично.

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

Почему?

Почему?

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

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

0. Зачем переписывать все сразу?

Ничего. Достаточно просто типизировать.

а как типизируется сценарий, ну к примеру есть тест, в котором проверяется что изменяя такой-то инпут, изменяется такое-то поле в state ?

0. Зачем переписывать все сразу?

тогда посыл был в том, чтобы не писать тесты, а писать типизацию?

тогда посыл был в том, чтобы не писать тесты, а писать типизацию?

Для компонентов да.

а как типизируется сценарий, ну к примеру есть тест, в котором проверяется что изменяя такой-то инпут, изменяется такое-то поле в state ?

или что компонент формы делает эвент submit

Я тоже считаю считаю, что тестирование компонентов это ад. Лучше писать тесты на логику

а как типизируется сценарий, ну к примеру есть тест, в котором проверяется что изменяя такой-то инпут, изменяется такое-то поле в state ?

Приватные данные, см. Стейт, не тестируются.

Я тоже считаю считаю, что тестирование компонентов это ад. Лучше писать тесты на логику

Что в этом подразумевается?

Я тоже считаю считаю, что тестирование компонентов это ад. Лучше писать тесты на логику

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

Приватные данные, см. Стейт, не тестируются.

почему? я хочу быть уверен в этом кейсе - я его тестирую, есть инструментарий удобный. why not…

Приватные данные, см. Стейт, не тестируются.

если типизация поможет в этом, просто можете кинуть ссыль куда глянуть, или лучше в паре слов опишите

почему? я хочу быть уверен в этом кейсе - я его тестирую, есть инструментарий удобный. why not…

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

ERROR: S client not available

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

“что такое внутренние контракты могут поменяться в любой момент” ? я свой тест так понимаю: если кто-то из команды вдруг изменит название поля или атрибут там или что-то еще, что повлияет на корректное изменение стейта - то быстро узнается, благодаря тесту

Что в этом подразумевается?

В начале жц проекта компоненты переписываются постоянно. Сидеть и дрочить на тдд компонентов странный фетиш, занимающий много времени

“что такое внутренние контракты могут поменяться в любой момент” ? я свой тест так понимаю: если кто-то из команды вдруг изменит название поля или атрибут там или что-то еще, что повлияет на корректное изменение стейта - то быстро узнается, благодаря тесту

Не делай супер огромные компоненты.

В начале жц проекта компоненты переписываются постоянно. Сидеть и дрочить на тдд компонентов странный фетиш, занимающий много времени

Нет я просто пытаюсь понять в чем отличие тестирование логики от тестирование компонентов

В начале жц проекта компоненты переписываются постоянно. Сидеть и дрочить на тдд компонентов странный фетиш, занимающий много времени

в начале жц я тоже не фанат тестов на компоненты

Нет я просто пытаюсь понять в чем отличие тестирование логики от тестирование компонентов

логика это критикал, компоненты второстепенное

логика это критикал, компоненты второстепенное

Еп, как пишутся тесты на логику? IQ?

логика это критикал, компоненты второстепенное

+1, но тестировать компоненты тоже полезно, имхо

Еп, как пишутся тесты на логику? IQ?

да, если меньше трех знаков, то на вью переходишь

да, если меньше трех знаков, то на вью переходишь

Если я написал тест, что компонент формы обрабатывает валидацию корректно, это логика или компонент?

+1, но тестировать компоненты тоже полезно, имхо

когда проект хотя бы в mvp

+1, но тестировать компоненты тоже полезно, имхо

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

Не делай супер огромные компоненты.

вот тут простой компонент тестируется - https://github.com/15Dkatz/react-tdd/blob/master/lootcheck/src/components/Wallet.test.js, не плохие же тесты? как их заменить типизацией?

Если я написал тест, что компонент формы обрабатывает валидацию корректно, это логика или компонент?

валидация функция => логика

валидация функция => логика

Отлично, тогда, я с самого начала спрашивал про логику

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

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

И теперь повторю вопрос. Есть ли дока (памятка) о том, какие логические вещи проверять в компонентах, пример я назвал выше.

Отлично, тогда, я с самого начала спрашивал про логику

не факт, вы спросили про компоненты, вам просто еще заодно подсказали про тестирование логики. Валидацию полей можно покрыть юнит тестами

И теперь повторю вопрос. Есть ли дока (памятка) о том, какие логические вещи проверять в компонентах, пример я назвал выше.

в компонентах логических вещей может быть миллион, не путайтесь, вопрос был нормальный изначально )

в компонентах логических вещей может быть миллион, не путайтесь, вопрос был нормальный изначально )

да тут шороху развели, 100 ответов и все в стиле "если iq небольшой иди во вью", мамкины сеньеры

да тут шороху развели, 100 ответов и все в стиле "если iq небольшой иди во вью", мамкины сеньеры

главное не получить РО за “хамство”, а в остальном тут бывают годные ответы. все норм)

Так кто так сказал про вью?

главное не получить РО за “хамство”, а в остальном тут бывают годные ответы. все норм)

Я сам тут раньше часто сидел, годноты тут много, согласен

Так кто так сказал про вью?

Вопросы?

А если нужно во вью контролировать передачу пропсов как то иначе? Вью становится сложнее

ща интересно пока про тестирование компонентов vs типизация, я пока не понял это.

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

Ок. Давай с другой стороны. От каких багов спасает тестирование вёрстки?)

От визуальных

да тут шороху развели, 100 ответов и все в стиле "если iq небольшой иди во вью", мамкины сеньеры

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

Давайте не будем сориться, а просто попытаемся отвечать по существу ? Проблема 1 - что критичное тестировать в компонентах Проблема 2 - как типизация заменяет тесты

От визуальных

Ты не в треде, мемчанский. Там не тесты скриншотов были)

Ок. Давай с другой стороны. От каких багов спасает тестирование вёрстки?)

там в примере не то чтобы верстку тестируют, а работу компонента.