Интересно, как защищаются от такой модфиикации настоящие программы? Они наверное подписывают свои файлы сертификатами, или даже через TPM во время установки?
/**
* Обработчик синтетического события
* @param {*} e Объект синтетического события
*/
const clickHandler = (e) => {
// Установка текущего значения рандомайзера
setCurrentValue(value);
};
Тут мемоизации нет, поэтому value актуальный. Если тут добавить useCallback(..., []) то возникнет та же проблема - value будет старым. И точно так же, если добавить value в deps все станет хорошо.
Дело тут, конечно, не в нативных/синтетических событиях, а в списке зависимостей useEffect. В первом случае Вы создаете clickHandler при каждом рендере и удаляете/добавляете нативный обработчик (внутри onclick={clickHandler}) Аналогичный код с нативными событиями будет, если в useEffect убрать [] и выполнять его на каждый render.
Есть библиотека libp2p для JS/Go/Rust в которой это уже реализовано, и много чего еще. Поднимается нода на сервере (или несколько) и на каждом клиенте. Соединяются с сервером через tcp/websocket/webtransport и получают адреса уже подключившихся клиентов - с каждым можно открыть webrtc соединение. После этого про сервер можно забыть, адреса новых клиентов будут распространяться через webrtc. Можно строить сеть только для открытого документа, а можно сразу для всех клиентов приложения, а поверх нее еще одну сеть для документа. А сервер можно и в качестве TURN использовать, только там это называется Relay. Самостоятельно это писать можно очень долго.
А 1 человеко-месяц react+nodejs разработчика стоит столько же как htmx+python/lavarel? Первых сейчас пруд-пруди любых уровней, а где вы берете вторых в нужном количестве, взращиваете сами, а потом удерживаете зарплатой в +20% к рынку?
Интересный очень проект, скажите, у Вас рендеринг в канвас идет в отдельных воркерах или в основных потоках окон? Используется ли BroadcastChannel для общения между окнами?
Звучит довольно похоже на SRP-6, там тоже на сервер не отправляется пароль, а только всякие криптографические хэши, из которых пароль нельзя получить. Для клиента есть рабочая реализация, для Go наверное тоже
А расскажите про openkey подробнее, это что-то похожее на SRP-6? Мне он нравится, но слишком уж повально все передают пароль в https, и не парятся. Так что я тоже забил. А если между терминирующим nginx и бекендом окажется дырявый логгер - то это проблема devops)
По бекенду: не только от количества пользователей сложность, может быть B2B проект под 100 пользователей но с большими нагрузками, сложной доменной моделью, многопоточными алгоритмами, ML, permissions, распределенными транзакциями, кафкой и всем остальным фаршем. Про аутентификацию не надо забывать, она обычно идет из коробки но есть нюансы. CORS это проблема бекенда, он запрещен по умолчанию в целях безопасности, поэтому клиент ругается. Не знаю, как там в Go, но в .Net все конечно идет из коробки, однако допиливать всегда что-то нужно. Конечно зависит от проекта, CRUD не проблема - но и на реакте todo-app за пару часов запилить можно, только кто за такие проекты платить будет? Во фронте проблема с зависимостями решается фикс версиями в package.json, я перешел на это пару лет назад и всем советую. Обновления большинства библиотек смело можно игнорировать. В переменной все что угодно - смотрите в сторону zod/yup. Валидируем данные с бекенда и от пользователя и больше не боимся атомной бомбы. С другими проблемами тоже есть решения: какой-нибудь jotai/mobx для управления состоянием. Да, технологий дофига нужно, сейчас к сайтам высокие требования в B2C. Вот в B2B полегче, там иногда можно ограничиться chrome/safari, 1440+, без поддержки мобилок, стандартный css из UI-framework.
Как будто на бекенде нет проблем, когда зоопарк сервисов на .Net Framework, .Net Core, python 2/3, Go, зависимости на фортране, деплой только в устаревший облачный оркестратор обвешанный костылями для поддержки всего этого. Ах да, особенности разных SQL БД и боттлнек в шине данных, как же без этого) Есть сложные фронтенды, есть сложные бекенды. Также как есть простые фронтенды и простые бекенды.
Согласен с этим, когда поддержка xattr есть это удобно. Но если их поддержки нет, или она по-другому работает, то все ломается) Ну вот не получается в linux на ntfs права выставить. А с rdf как раз удобно - права на файл прописаны в файле, все есть файл, аминь) И этот файл существовал бы и в linux и в windows одинаково, на любой ФС.
А вы рассматривали возможность упаковать PWA в нативное приложение и отправить в AppStore/GooglePlay?
GC не вешается от такого "эффективного процесса"?
Очень просто, но полезно
Интересно, как защищаются от такой модфиикации настоящие программы? Они наверное подписывают свои файлы сертификатами, или даже через TPM во время установки?
Я про первый кейс с синтетическими событиями
Тут мемоизации нет, поэтому value актуальный. Если тут добавить
useCallback(..., [])то возникнет та же проблема - value будет старым. И точно так же, если добавитьvalueвdepsвсе станет хорошо.Дело тут, конечно, не в нативных/синтетических событиях, а в списке зависимостей useEffect. В первом случае Вы создаете
clickHandlerпри каждом рендере и удаляете/добавляете нативный обработчик (внутриonclick={clickHandler}) Аналогичный код с нативными событиями будет, если в useEffect убрать [] и выполнять его на каждый render.Если смотреть на стандарты, то можно взять W3C RDF vCard: https://www.w3.org/2006/vcard/ns-2006.html#Name
Там
familyNameиgivenNameЕсть библиотека libp2p для JS/Go/Rust в которой это уже реализовано, и много чего еще. Поднимается нода на сервере (или несколько) и на каждом клиенте. Соединяются с сервером через tcp/websocket/webtransport и получают адреса уже подключившихся клиентов - с каждым можно открыть webrtc соединение. После этого про сервер можно забыть, адреса новых клиентов будут распространяться через webrtc. Можно строить сеть только для открытого документа, а можно сразу для всех клиентов приложения, а поверх нее еще одну сеть для документа. А сервер можно и в качестве TURN использовать, только там это называется Relay.
Самостоятельно это писать можно очень долго.
А 1 человеко-месяц react+nodejs разработчика стоит столько же как htmx+python/lavarel?
Первых сейчас пруд-пруди любых уровней, а где вы берете вторых в нужном количестве, взращиваете сами, а потом удерживаете зарплатой в +20% к рынку?
По моему опыту SVG выигрывает при небольшом числе фигур, выше 1000 уже сильно тормозит при отрисовке по сравнению с OffscreenCanvas.
Интересный очень проект, скажите, у Вас рендеринг в канвас идет в отдельных воркерах или в основных потоках окон? Используется ли BroadcastChannel для общения между окнами?
Звучит довольно похоже на SRP-6, там тоже на сервер не отправляется пароль, а только всякие криптографические хэши, из которых пароль нельзя получить. Для клиента есть рабочая реализация, для Go наверное тоже
А расскажите про openkey подробнее, это что-то похожее на SRP-6? Мне он нравится, но слишком уж повально все передают пароль в https, и не парятся. Так что я тоже забил. А если между терминирующим nginx и бекендом окажется дырявый логгер - то это проблема devops)
По бекенду: не только от количества пользователей сложность, может быть B2B проект под 100 пользователей но с большими нагрузками, сложной доменной моделью, многопоточными алгоритмами, ML, permissions, распределенными транзакциями, кафкой и всем остальным фаршем. Про аутентификацию не надо забывать, она обычно идет из коробки но есть нюансы. CORS это проблема бекенда, он запрещен по умолчанию в целях безопасности, поэтому клиент ругается. Не знаю, как там в Go, но в .Net все конечно идет из коробки, однако допиливать всегда что-то нужно. Конечно зависит от проекта, CRUD не проблема - но и на реакте todo-app за пару часов запилить можно, только кто за такие проекты платить будет?
Во фронте проблема с зависимостями решается фикс версиями в package.json, я перешел на это пару лет назад и всем советую. Обновления большинства библиотек смело можно игнорировать.
В переменной все что угодно - смотрите в сторону zod/yup. Валидируем данные с бекенда и от пользователя и больше не боимся атомной бомбы. С другими проблемами тоже есть решения: какой-нибудь jotai/mobx для управления состоянием.
Да, технологий дофига нужно, сейчас к сайтам высокие требования в B2C. Вот в B2B полегче, там иногда можно ограничиться chrome/safari, 1440+, без поддержки мобилок, стандартный css из UI-framework.
Как будто на бекенде нет проблем, когда зоопарк сервисов на .Net Framework, .Net Core, python 2/3, Go, зависимости на фортране, деплой только в устаревший облачный оркестратор обвешанный костылями для поддержки всего этого. Ах да, особенности разных SQL БД и боттлнек в шине данных, как же без этого)
Есть сложные фронтенды, есть сложные бекенды. Также как есть простые фронтенды и простые бекенды.
Там в первой формуле -1 в кубе, а во второй в четвертой степени, это зачем так? И что такое альфа, и почему оно в 25 или 98 степени?
Согласен с этим, когда поддержка xattr есть это удобно.
Но если их поддержки нет, или она по-другому работает, то все ломается) Ну вот не получается в linux на ntfs права выставить. А с rdf как раз удобно - права на файл прописаны в файле, все есть файл, аминь) И этот файл существовал бы и в linux и в windows одинаково, на любой ФС.
В принципе никто не мешает развернуть pod локально.
А у оффлайн-онли хранилища есть вполне очевидный минус - нет доступа с других устройств.
А в чем принципиальная разница между xattr и RDF?