Все верно. В зависимости от того, с кем вы общаетесь Frontend, Backend разработчком или архитектором, представление о реактивном программировании может немного отличаться.
Но кажется что обычно все сходятся на примерно этом свойстве.
The ability to describe a system like: a = b + c
And have that relationship represent a rule rather than an assignment. To ensure a always equals the sum of b and c were b or c to ever change. And that relationship never changes.
То есть зависимые данные должны обновляться автоматически и всегда.
Вот как раз всегда и автоматически React не удовлетворяет. И существенно ограничивает, где эти потоки можно определять ( только в рамках компонент).
Не всегда и не автоматически так как есть завязка на отрисовку React и на компоненты, в рамках которых реактивность живет.
Иногда надо сделать явно setState. Иногда - обновление вообще не произойдет.
На мой взгляд можно считать React реализующим принципы реактивного программирования большой натяжкой, с существенными ограничениями, и только в привязке к компонентам. Достаточно этого или нет - вопрос открытый. Как по мне - то нет.
Даже сами разработчики никогда не заявляли React как реактивное программирование.
Вот цитата Dan Abramov, одного из ключевых фигур в React и Redux, про название React и отношение к Reactive programming.
«Yeah I don't think we have anything beyond Jordan considering rendering "reactive" to changing inputs. Even though it's not strictly reactive programming.»
Я не писал Вам по поводу отсутствия реактивности в React. Только о том что он не выполняет все принципы реактивного программирования, которое оперирует потоками данных.
Нет смысла забирать/обрабатывать данные, если в конечном итоге все данные идут в отрисовку. Но это не всегда так, не со всеми данными.
Я не говорил и не спорил про push и pull подход, и что это как-то влияет на отношение к функциональному реактивному программированию. По предложенной ссылке, команда React говорила частично про push подход, да, но больше про то, что вся логика там напрочь связана с тем что отрисовывается на экране.
React is not a generic data processing library. It is a library for building user interfaces.
If something is offscreen, we can delay any logic related to it. If data is arriving faster than the frame rate, we can coalesce and batch updates.
Думаю, именно поэтому ее и предложили в шутку назвать Schedule, а не из-за pull-based подхода.
Думаю, что дальше бессмысленно продолжать дискуссию. Пусть каждый останется при своем.
Все-таки useEffect вызывается после перерисовки компонента, а не непосредственно в ответ на изменение данных. Это связывает реактивность в React с жизненным циклом компонентов, а не с потоками данных, как в классическом реактивном программировании.
useEffect может банально не вызваться, если при перерисовке компонента произошла ошибка.
На самом деле тут немного про разную реактивность.
Реактивное программирование — это парадигма, основанная на потоках данных (data streams) и распространении изменений
В React реактивность в реагировании и перестройке интерфейса при изменении состояния.
Так что если рассматривать React как сильно урезанную версию реактивного программирования, без явных потоков, императивно и с завязкой на компоненты, то можно притянуть. Но кажется этот спор немного бессмысленен.
Благодарю, спасибо Вам большое! Перепроверил, действительно, была строка с any типом в примере. Ума не приложу, как это сработало в онлайн редакторе, в котором я запускал код. Там явно был выбран язык Javascript. Но тут как в том анекдоте про встречную полосу - второй человек который мне это сказал - заставил меня задуматься, что что-то не так)
Небольшое отступление. В целом же насчет типизации - на мой взгляд она на интервью излишняя и может привнести больше проблем чем пользы. Это и потраченное время, которое может пойти на другие задачи, и раздосадованный этим интервьюер. Лучше такие вещи уточнить у интервьюера, который скорее всего скажет что делать типизацию не нужно.
Очень интересно. Я тоже так думаю. Метод у Promise в then будет выполняться только когда Call Stack пуст, а это значит что переполнения стека быть не должно.
Существуют разные варианты throttle. Некоторые ведут себя как Вы говорите, некоторые просто не выполняют вызов. Это зависит от постановки, которую лучше уточнить на интервью, когда дается задача.
Обратите внимание, примеры на JS, поэтому нет типизации.
Все верно. В зависимости от того, с кем вы общаетесь Frontend, Backend разработчком или архитектором, представление о реактивном программировании может немного отличаться.
Но кажется что обычно все сходятся на примерно этом свойстве.
The ability to describe a system like:
a = b + cAnd have that relationship represent a rule rather than an assignment. To ensure
aalways equals the sum ofbandcwereborcto ever change. And that relationship never changes.То есть зависимые данные должны обновляться автоматически и всегда.
Вот как раз всегда и автоматически
Reactне удовлетворяет. И существенно ограничивает, где эти потоки можно определять ( только в рамках компонент).Не всегда и не автоматически так как есть завязка на отрисовку
Reactи на компоненты, в рамках которых реактивность живет.Иногда надо сделать явно
setState. Иногда - обновление вообще не произойдет.На мой взгляд можно считать
Reactреализующим принципы реактивного программирования большой натяжкой, с существенными ограничениями, и только в привязке к компонентам. Достаточно этого или нет - вопрос открытый. Как по мне - то нет.Даже сами разработчики никогда не заявляли React как реактивное программирование.
https://github.com/facebook/react/issues/14606#issuecomment-455259782
Вот цитата Dan Abramov, одного из ключевых фигур в React и Redux, про название React и отношение к Reactive programming.
«Yeah I don't think we have anything beyond Jordan considering rendering "reactive" to changing inputs. Even though it's not strictly reactive programming.»
Ну как будто назвать Netflix простым, даже с точки зрения GUI, приложением - сильное упрощение.
Youtube же Вы наверное не считаете простым с точки зрения UI/UX взаимодействия приложением? Чем Netflix кардинально отличается?
Netflix - один из главных евангелистов RxJs. Начал использовать RxJs еще до Angular 2, как раз для решения проблем в реализации сложной бизнес логики.
Я не писал Вам по поводу отсутствия реактивности в React. Только о том что он не выполняет все принципы реактивного программирования, которое оперирует потоками данных.
Нет смысла забирать/обрабатывать данные, если в конечном итоге все данные идут в отрисовку. Но это не всегда так, не со всеми данными.
Я не говорил и не спорил про push и pull подход, и что это как-то влияет на отношение к функциональному реактивному программированию. По предложенной ссылке, команда React говорила частично про push подход, да, но больше про то, что вся логика там напрочь связана с тем что отрисовывается на экране.
React is not a generic data processing library. It is a library for building user interfaces.If something is offscreen, we can delay any logic related to it. If data is arriving faster than the frame rate, we can coalesce and batch updates.Думаю, именно поэтому ее и предложили в шутку назвать Schedule, а не из-за pull-based подхода.
Думаю, что дальше бессмысленно продолжать дискуссию. Пусть каждый останется при своем.
Все-таки
useEffectвызывается после перерисовки компонента, а не непосредственно в ответ на изменение данных. Это связывает реактивность в React с жизненным циклом компонентов, а не с потоками данных, как в классическом реактивном программировании.useEffectможет банально не вызваться, если при перерисовке компонента произошла ошибка.На самом деле тут немного про разную реактивность.
Реактивное программирование — это парадигма, основанная на потоках данных (data streams) и распространении изменений
В React реактивность в реагировании и перестройке интерфейса при изменении состояния.
Так что если рассматривать React как сильно урезанную версию реактивного программирования, без явных потоков, императивно и с завязкой на компоненты, то можно притянуть. Но кажется этот спор немного бессмысленен.
Команда React сама официально декларирует что не хотела бы чтобы React удовлетворял принципам реактивного программирования https://ru.legacy.reactjs.org/docs/design-principles.html#scheduling
Благодарю, спасибо Вам большое! Перепроверил, действительно, была строка с any типом в примере. Ума не приложу, как это сработало в онлайн редакторе, в котором я запускал код. Там явно был выбран язык Javascript. Но тут как в том анекдоте про встречную полосу - второй человек который мне это сказал - заставил меня задуматься, что что-то не так)
Небольшое отступление. В целом же насчет типизации - на мой взгляд она на интервью излишняя и может привнести больше проблем чем пользы. Это и потраченное время, которое может пойти на другие задачи, и раздосадованный этим интервьюер. Лучше такие вещи уточнить у интервьюера, который скорее всего скажет что делать типизацию не нужно.
Очень интересно. Я тоже так думаю. Метод у Promise в then будет выполняться только когда Call Stack пуст, а это значит что переполнения стека быть не должно.
Существуют разные варианты throttle. Некоторые ведут себя как Вы говорите, некоторые просто не выполняют вызов. Это зависит от постановки, которую лучше уточнить на интервью, когда дается задача.
Обратите внимание, примеры на JS, поэтому нет типизации.