>>> не надо всё запихивать в компоненты
>> А у JS-фанов нет выбора.
У JS-фанов компонент — это View. У них своя терминология и ветвь эволюции с неизвестными корнями. То что десятилетиями было очевидно в зрелых языках, они осознают только сейчас.
У меня дома Nvidia Shield TV с GameStream и комп в офисной квартире. Оба девайса под роутерами и натами. Решил проблему поднятием P2P-сети через NeoRouter Mesh. Пинг 3 мс, все отлично.
Разве здесь не должен быть useState(ChaAPI.friendsStatus[friendID].isOnline), и что тогда будет, если придет значение с другим friendID? Поскольку это initialState, то значение isOnline не изменится. Как это разрулить хуками?
Ну а что делать, сам Electron в текущем виде это конечно костыль для разработки кроссплатформенных приложений, но и более эффективных альтернатив пока не видно.
Или что-то свое кастомное? Не приведет ли кастомное к ошибкам. Например сервер возвращает строку «wrong_email_or_password», а на клиенте при проверке на равенство я потерял букву.
Кастомные. Тут можно использовать строковые константы. Если бэкенд на ноде, то можно использовать общий код, иначе держать константы в синхронизированном виде для обоих частей.
Имхо, вся обязанность бэкенда — это отдать код ошибки и все полезные с ней данные, а как отобразить ее пользователю и на каком языке — это уже ответственность клиентской части.
Это не Flux, у вас нет диспетчера и Action не как событие. Сегодня на фронтэнде без этого никак, иначе слишко будет легко. А вообще такой подход можно использовать в связке mobx/immer и получить как бонус точечное обновление компонентов.
Иногда проще в каком-нибудь методе для Dictionary/HashSet заюзать Tuple, чем городить под это дело целый класс с однотипной реализацией override Equals.
>> А у JS-фанов нет выбора.
У JS-фанов компонент — это View. У них своя терминология и ветвь эволюции с неизвестными корнями. То что десятилетиями было очевидно в зрелых языках, они осознают только сейчас.
О как исковеркали древний анекдот — одни яйца сохранились.
mobx — это про MVVM. За состояние V отвечает VM.
Разве здесь не должен быть useState(ChaAPI.friendsStatus[friendID].isOnline), и что тогда будет, если придет значение с другим friendID? Поскольку это initialState, то значение isOnline не изменится. Как это разрулить хуками?
Можно дать юзеру возможность сгенерировать и скопировать пароль.
Ну а что делать, сам Electron в текущем виде это конечно костыль для разработки кроссплатформенных приложений, но и более эффективных альтернатив пока не видно.
Как мне видится, гамбургер это больше про второстепенную навигацию и он все же нужен, а вот у авторов там похоже находилась основная.
Кастомные. Тут можно использовать строковые константы. Если бэкенд на ноде, то можно использовать общий код, иначе держать константы в синхронизированном виде для обоих частей.
Имхо, вся обязанность бэкенда — это отдать код ошибки и все полезные с ней данные, а как отобразить ее пользователю и на каком языке — это уже ответственность клиентской части.
Промежуточные переменные нужны для самодокуменирования кода, чтобы потом коллегам не приходилось взламывать ваш однострочник.
Это не Flux, у вас нет диспетчера и Action не как событие. Сегодня на фронтэнде без этого никак, иначе слишко будет легко. А вообще такой подход можно использовать в связке mobx/immer и получить как бонус точечное обновление компонентов.
Я бы прикрутил теги.
TS -> EsNext -> Babel — лучший вариант — поддержка плагинов + конфигурируемая транспиляция
Иногда проще в каком-нибудь методе для Dictionary/HashSet заюзать Tuple, чем городить под это дело целый класс с однотипной реализацией override Equals.