Да, согласен со сказанным. Работать с тем, над чем нет контроля это плохая идея, именно поэтому я не полез в поиски того, как можно управлять расположением окон браузера и глубже. Но на уровне просто открыть дополнительное окно вполне всё контролируемо из JS.
А по поводу ожидания пользователей, это да. Для большинства пользователей от этого будет больше вреда. Думая над данным решением я предполагал, что это можно применять для узкого круга пользователей, которые точно готовы к разделению на несколько окон. В моем представлении это либо разработчик, который привык работает в несколько экранов, либо специфичное приложение не для широкой публики с четкой инструкцией об этой части функционала.
Хотел бы отметить, что redux-state-sync под капотом использует Broadcast Channel API. Я не говорю про то, что данное решение супер быстрое и не застраховано от тормозов, к сожалению, тесты я не проводил. Просто хотел прояснить на чем работает и избежать путанности.
У самого же redux-state-sync есть возможность записи в блэклист состояний, которые не должны меняться в разных окнах, что возможно сокращает объем передаваемых данных между окнами до необходимого минимума.
Касаемо ухода неактивного окна в спящий режим, не очень понял проблему. Ушел и ушел, если пользователь им не пользуется пусть и весит в таком состоянии, это не должно никак мешать.
А насчет «подключить готовую библиотеку». Изначально я думал что придется самому писать инструмент для синхронизации изменения состояния между вкладками, в этом и была идея, но да, нашел готовое, которое прекрасно работает и я был рад. А статью решил написать больше не по коду а просто по идеи и возможности делать вот так вот
Насчет объяснения того, почему функционал не востребован, действительно не раскрыл в статье. Но ответ достаточно прост, и очень тесно связан как раз с тем, что вы написали в первых абзацах. Обычному пользователю данный функционал будет сильно непривычен и неудобен.
В целом, мне кажется, подавляющее большинство пользователей для просмотра браузера используют только один монитор, что действительно делает для них данных функционал неприменимым, и даже мешающим.
Но есть всё же группа пользователей, которым подойдет данная идея. Она применима к сайтам "для разработчиков", когда пользователь привык работать с несколькими мониторами и не потеряется от этого.
Я говорю про сайты на подобии этого: https://easyeda.com/ru . Наверное, лучший пример, где рассмотренная идея может применяться, множество дополнительных панелей и кнопок + пользователь разработчик, который привык пользоваться несколькими дисплеями.
Зачем я предложил этот "третий" вариант, и вообще решил, что его можно выделить?
Скорее всего просто потому что сам хотел избежать обращение к элементу через JS, потому что читал, что css анимация лучше, чем менять стили через JS, и потому что в React не хотел писать весь необходимый JS с обращением к элементам.
Но основная причина в том, что такой метод точно есть (у меня же заработало), а в интернете его описание не нашел. Поэтому решил что это прекрасная возможность попробовать себя в написании статей).
А вопрос, что лучше в плане производительности, мне интересен, но до его изучения ещё не добрался.
Первоначально про stroke-dasharray и stroke-dashoffset. Не использовал только потому что не знал про такой способ (ещё не доводилось работать с svg анимацией), а при запросе во всемирную сеть "как анимировать границу блока" множество сайтов предложило вариант решения через псевдоэлементы, в частности тот, на который я давал ссылку. Но сейчас, изучив ваше предложение, действительно такую границу, скорее всего, лучше делать через svg анимацию.
А по поводу статьи в целом, она всё же не про конкретную реализацию "бегущей" границы, а про css анимацию с помощью styled components. Просто рассказывать было проще на примере. То есть тут про избегание настройки анимации через обращение к элементам по средствам JS. То есть про то, что можно записать анимацию keyframes через переменные, используя CSS-in-JS, и она будет создаваться при новом рендеринге на основе входных данных.
Даже если использовать stroke-dasharray и stroke-dashoffset можно применить предложенный подход, и составить ключевые кадры на основе переменных для них, и избежать использования JS.
Суть не в анимации границы, а в избегании обращения к элементам через JS. То есть, если мы вдруг захотим, чтобы в компонент можно было бы передать пропс с цветом цифры, причем так, что можно задать цвет счетчика в момент счета и по завершению, вариантов реализации всего несколько (если не ошибаюсь):
Через JS обращаться к элементу и менять его цвет через style.
Через JS вешать на элементы класс с соответствующим цветом.
И я предлагаю третий вариант, без необходимости обращении к элементу через JS
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Интересно, я искал где такое применяют, но про вынос чатов не нашел, спасибо за комментарий.
Я думал больше про приложения другого типа, к примеру: https://easyeda.com/ru.
А про ненужность функционала я действительно переборщил, скорее просто редкость и как следствии мало информации о том, как это сделать.
Да, согласен со сказанным. Работать с тем, над чем нет контроля это плохая идея, именно поэтому я не полез в поиски того, как можно управлять расположением окон браузера и глубже. Но на уровне просто открыть дополнительное окно вполне всё контролируемо из JS.
А по поводу ожидания пользователей, это да. Для большинства пользователей от этого будет больше вреда. Думая над данным решением я предполагал, что это можно применять для узкого круга пользователей, которые точно готовы к разделению на несколько окон. В моем представлении это либо разработчик, который привык работает в несколько экранов, либо специфичное приложение не для широкой публики с четкой инструкцией об этой части функционала.
Хотел бы отметить, что redux-state-sync под капотом использует Broadcast Channel API. Я не говорю про то, что данное решение супер быстрое и не застраховано от тормозов, к сожалению, тесты я не проводил. Просто хотел прояснить на чем работает и избежать путанности.
У самого же redux-state-sync есть возможность записи в блэклист состояний, которые не должны меняться в разных окнах, что возможно сокращает объем передаваемых данных между окнами до необходимого минимума.
Касаемо ухода неактивного окна в спящий режим, не очень понял проблему. Ушел и ушел, если пользователь им не пользуется пусть и весит в таком состоянии, это не должно никак мешать.
А насчет «подключить готовую библиотеку». Изначально я думал что придется самому писать инструмент для синхронизации изменения состояния между вкладками, в этом и была идея, но да, нашел готовое, которое прекрасно работает и я был рад. А статью решил написать больше не по коду а просто по идеи и возможности делать вот так вот
Насчет объяснения того, почему функционал не востребован, действительно не раскрыл в статье. Но ответ достаточно прост, и очень тесно связан как раз с тем, что вы написали в первых абзацах. Обычному пользователю данный функционал будет сильно непривычен и неудобен.
В целом, мне кажется, подавляющее большинство пользователей для просмотра браузера используют только один монитор, что действительно делает для них данных функционал неприменимым, и даже мешающим.
Но есть всё же группа пользователей, которым подойдет данная идея. Она применима к сайтам "для разработчиков", когда пользователь привык работать с несколькими мониторами и не потеряется от этого.
Я говорю про сайты на подобии этого: https://easyeda.com/ru . Наверное, лучший пример, где рассмотренная идея может применяться, множество дополнительных панелей и кнопок + пользователь разработчик, который привык пользоваться несколькими дисплеями.
Зачем я предложил этот "третий" вариант, и вообще решил, что его можно выделить?
Скорее всего просто потому что сам хотел избежать обращение к элементу через JS, потому что читал, что css анимация лучше, чем менять стили через JS, и потому что в React не хотел писать весь необходимый JS с обращением к элементам.
Но основная причина в том, что такой метод точно есть (у меня же заработало), а в интернете его описание не нашел. Поэтому решил что это прекрасная возможность попробовать себя в написании статей).
А вопрос, что лучше в плане производительности, мне интересен, но до его изучения ещё не добрался.
Спасибо за комментарий.
Первоначально про
stroke-dasharrayиstroke-dashoffset. Не использовал только потому что не знал про такой способ (ещё не доводилось работать с svg анимацией), а при запросе во всемирную сеть "как анимировать границу блока" множество сайтов предложило вариант решения через псевдоэлементы, в частности тот, на который я давал ссылку. Но сейчас, изучив ваше предложение, действительно такую границу, скорее всего, лучше делать через svg анимацию.А по поводу статьи в целом, она всё же не про конкретную реализацию "бегущей" границы, а про css анимацию с помощью styled components. Просто рассказывать было проще на примере. То есть тут про избегание настройки анимации через обращение к элементам по средствам JS. То есть про то, что можно записать анимацию keyframes через переменные, используя CSS-in-JS, и она будет создаваться при новом рендеринге на основе входных данных.
Даже если использовать
stroke-dasharrayиstroke-dashoffset можно применить предложенный подход, и составить ключевые кадры на основе переменных для них, и избежать использования JS.Суть не в анимации границы, а в избегании обращения к элементам через JS. То есть, если мы вдруг захотим, чтобы в компонент можно было бы передать пропс с цветом цифры, причем так, что можно задать цвет счетчика в момент счета и по завершению, вариантов реализации всего несколько (если не ошибаюсь):
Через JS обращаться к элементу и менять его цвет через style.
Через JS вешать на элементы класс с соответствующим цветом.
И я предлагаю третий вариант, без необходимости обращении к элементу через JS