Главная проблема в том, что подход "пропсы вниз - сообщения вверх" придуманы не просто так, а чтобы не распутывать потом клубок "кто-же где-же таки изменил эту переменную?!"
По-этому, ИМХО (и собственно так в официальной документации) - инжектить любую переменную нужно через readonly вместе с методом, который может эту переменную изменять, и в компоненте не изменять данную переменную напрямую, а использовать метод. Это реально уберегает от очень многих головняков (хотя бы потому, что для простой отладки будет достаточно добавить в данный метод печать трейса, чтобы понять "кто-же где-же").
Исключения, естественно, есть - очень тесно связанные компоненты и не более одного уровня (т.е. родитель-ребенок). Например табы (родительский холдер и его дети, собственно, сами табы). Но и там, чтобы не плодить "везде делаем так, а вот здесь можно не так" и поддерживать некоторую гомогенность системы, я бы все сделал через readonly + метод.
Вы требования их сервера синхронизации видели? Если не видели - посмотрите.
Это даже не стрельба гаубицей по воробьям - там можно целый сервис высокнагруженного бизнеса на этом решении организовать, а не то что файл конфигурации синхронизировать.
Нужна нормальная база данных, а не колхоз с файлом.
Расскажите это SQLlite-у, который, собственно, в Mozilla-вских продуктах широко используется.
Достаточно положить один файл SQLite, и выполнять синхронизацию от любого кол-ва устройств.
Да и, честно, вообще проблем сделать это хоть с одним файлом с JSON ни каких нет - с помощью блокировок все это решаемо. Конфликт может быть только при обновлении.
При синхронизации заблокировал (остальные ждут освобождения), синхронизировал, разблокировал - все - будет работать вполне нормально, без каких-либо конфликтов.
Как сделать сигнал блокировки - можно атрибутами файла, переименовыванием, созданием лок-файла рядом - вариантов также масса.
Есть только один риск - если приложение упало не разблокировав файл - решается временной меткой файла - если с момента блокировки прошло достаточно много врмени, форсить разблокировку-блокировку.
Чтобы было подобие транзакционности и избежать неконсистентности делают так: блокируют основной файл, пишут файл рядом, переименовывают записанный файл в основной файл, снимают блокировку. Это обеспечивает консистентность.
Больше всего задалбывают те, кто начинает критиковать, не разобравшись,
Я, как раз, разбирался - и то, что там предлагают - нормально не юзабельно. Я решил это проблему самописным экстеншеном (синхронизация закладок/открытых вкладок - мне больше ничего не надо), но да - с бд на своем собственном сервере, так как она уже там была. Мог сделать и через один файл.
Прежде чем навшивать ярлыки на собеседника, может быть стоило поинтересоваться его опытом?
А если серьезно - то задолбали бесполезные изменения аля "нововведения" и попытки затащить пользователей к себе.
Понятно почему очень хочется, но хотя-бы в одной альтернативе могли этого не делать или сделать возможность сторить данные в виде одного файла по указанной ссылке - тогда это можно было класть это куда угодно - хочешь - к ним на сервер, хочешь - в дропбокс, хочешь - к себе на vds.
Конечно, технология виновата, а не сами люди. Это-ж технология подкладывает себя людям в игрушки!
А ещё надо запретить жпс-трекеры, сотовые телефоны и фонарики!
Apple недостаточно информирует о технологиях, научные журналы вообще охренели - ничего не понятно, а у людей лапки!!!
Вчера, выходя из бара асфальт стал пониматься и бить поситителей по голове! Нужно, чтобы дорожные службы информировали поситителей, что нельзя так бухать!
Написание кода, именно набор текста, занимает довольно небольшую долю времени погромиста.
Кроме просто написания, это нужно еще продумать.
Компилятор следит.
Компилятор следит за верностью использования, а не за бизнес-логикой, "следить" в этом случае - это использовать согласно задаче, а не в плане правильно/неправильно
Типизация "настраивается" 1 раз, а дальше оно само.
Нет, само оно только подсказывает типы, если они уже написаны, никто за вас автоматом типы в функцию или класс, который еще не написан, как и его составлюящие, не подставит, если он состоит из новых сущностей.
Т.е. программирование таки разделяется на две вещи, как я уже выше писал - создание/изменение типов там где нужно, и сама программа, это использующая , для решения задачи бизнеса.
Грубо говоря, если вам надо описать что-то из чего-то - вы вынуждены будете описать тип того, что хотите в контейнер пооложить, а потом объявить контейнер соответствующего типа. Никто за вас это не сделает. В языка со слабой типизацией вы просто объявили контейнер и кладете туда все что хотите.
И еще раз - мой посыл не в том, что слабая или сильная типизация плохи или хороши, а в том, что они дают разные преимущества.
Оттуда, что не надо описывать дополнительно типы, следить за ними и их использованием.
Кроме того, когда пишешь фии и еще неизвестно что она должна возвращать (POC например) - с этим тоже можно не заморачиваться и дописать позже и тд.
Вобщем как раз из-за того, что при использовании типов ты как бы два рилма в голове держишь - рилм кода бизнес-логики и рилм типов, этот код обслуживающий.
Молоток - очень крутая штука, я реально не понимаю людей, которые используют отвертку! Ведь молотком можно и гвозь забивать и шуруп!
Очередная статья из серии "Кто сильнее Акула или Медведь?".
Это все - инструменты. Умение их использовать открывает вам соответсвующие двери и наоборот.
Правильно настроенный линтер на языке со слабой типизацией сводит практически все описанные ошибки на нет. Скорость разработки POCов или каких-либо конверторов данных для разовых операций идет гораздо быстрее на языках со слабой типизацией - один из сильных вариантов их использования.
Тяжелый проект, сторящийся на века и поддерживаемый командой - да, нужно писать с типизацией - на дает соотвествующую выгоду, расплата за это - время написания кода.
Вот и все - но нет, опять появляются остроконечники vs тупоконечники.
Еще раз - языки - это инструменты, универсального нет - выбирая один, ты всегда в чем-то выигрываешь, а в чем-то проигрываешь.
Справедливости ради, быковать начал как раз другой партнер.
Доказательство чипов-шпионов и тд так и не предоставили. Ну и тп.
Это вовсе не означает, что КНР белый и пушистый, но то, что он сделал и почему - как раз не связано с их быкованием - они достаточно честно себе вели с партнерами, чего не сказать про них. Их мотивы тоже понятны, но вот поведение - не очень.
Ну и не надо китайцев за дураков деражть - они прекрасно мониторят рынок и в случае появления "конкурентов" будет работать старая добрая схема с демпингом.
Те господа импортозамещатели даже не в курсе, что в разных языках слова могут иметь разные оттенки смысла и переводить их "в лоб" не очень хорошо.
P. S. емнип создатели его так назвали держа в голове как раз слэнговый оттенок, который можно на русский грубо перевести так "из искры возгорится пламя", фитиль тут не причём, скорее больше подходит русское слово "растопка", ну или "дрова". То, что понимают у нас под словом "фитиль" проводится на английский как wick. Именно по-этому у меня даже асссоциаций не возникало.
Вот и назвали бы свой сервис "Искра" — оно по смыслy как раз бьется с оттенком слова tinder + на русском есть оттенок этого слова в плане отношений.
Ну или "Фертиль" — было бы по делу, с юмором, отсылкой и на французский манер)
Ответьте пожалуйста на один вопрос — доколе это будет на Хабре? Каждый пост минусуют — вам это ни о чем не говорит?
Попытки высосать техническую составляющую из пальца (или откуда там у вас) в статье выглядят смешно и нелепо.
Одно только ваше название вызывает у людей чуть постарше ассоциацию с одним очень интересным, но далёким от знакомств, журналом — и из-за диссонанса это вызывает раздражение, а помладше даже слова такого не знают, что, в принципе, вполне нормально. Страшно подумать, откуда оно взялось для такого сервиса. У меня только старый анекдот напрашивается про дядьку с животом в бане, бомбу, двух ребятишек и короткий фитиль…
Кроме того, в силу некоторых обстоятельств (которые ведомы большинству, но почему-то неведомы тем, кто пытается "предоставлять" услуги на данном поле) на всех подобных сервисах знакомств всегда много М и очень мало Ж, однако вы упорно пытаетесь постить статьи на ресурсе с точно таким-же перекосом.
Я даже и не знаю, что вам сказать после этого…
ИМХО регистрироваться у вас при таком подходе точно не надо.
Я, если честно, не понял, зачем нужно SWO/VCP в программаторе?
Т.к. любая (ну или почти любая ) ножка процессора элементарно превращается в UART либо что-либо еще аппаратно, либо битбэнгом - и выводит или вводит все, что душе угодно.
Вирутальный COM? - да вообще без проблем - цепляешь UART к UART2USB с али за 1$ и все - можно отправлять/принимать что угодно, мало того, их можно присоеденить не один, а несколько к разным ножкам и гнать телеметрию по всем ним.
В win10 эта настройка не работает — окна на панели управления продолжают перетаскиваться скопом, если это одна и таже программа, это очень старый баг.
Те стандартными средствами добиться нормального поведения невозможно.
Баг этот был найден давным-давно и находится в exolorer-e или каком-то его компоненте, который и патчится в рантайме сторонними программами и до сих пор так и не прфикшена, как и проблема с тенями с подписями иконок рабочего стола.
Там все более менее, спасибо вашим статьям, там проблема в другом — практически все браузеры сейчас "заботятся о безопасности" и не дают сохранять файлы локально. Те прочесть не сложно, а вот сохранить.
Вы мои комментарии выше перечитайте еще раз - у меня где-то что-то написано про фреймворк? Речь про данные, а не про фреймворки - когда получится это осилить - можно будет продолжать разговор.
Еще раз - проблемы возникают не из-за фреймворка, а из-за множественных источников изменения. От фреймворка в данном случае ничего не зависит, можно и во Vue, если очень хочется, изменять пропс (через функцию, например).
Но потом отлавливать где же что установило некорректное значение, и почему появилась петля в данных будет вашим личным адом.
В минимзации всего и вся - обращений к бэку, размера этих обращений, рендеринга, их дебаунс и объединение + универсализации компонент и фронта в целом (из-за огромной фрагментации устройств, с которых сидят пользователи) и тд.
Объяснять это в комментарии долго - это тема целых докладов на хайлоадах.
Есть огромная пропасть между приложениями на десятки пользователей и на десятки тысяч на фронте. Про бэк я вообще молчу.
Главная проблема в том, что подход "пропсы вниз - сообщения вверх" придуманы не просто так, а чтобы не распутывать потом клубок "кто-же где-же таки изменил эту переменную?!"
По-этому, ИМХО (и собственно так в официальной документации) - инжектить любую переменную нужно через readonly вместе с методом, который может эту переменную изменять, и в компоненте не изменять данную переменную напрямую, а использовать метод. Это реально уберегает от очень многих головняков (хотя бы потому, что для простой отладки будет достаточно добавить в данный метод печать трейса, чтобы понять "кто-же где-же").
Исключения, естественно, есть - очень тесно связанные компоненты и не более одного уровня (т.е. родитель-ребенок). Например табы (родительский холдер и его дети, собственно, сами табы). Но и там, чтобы не плодить "везде делаем так, а вот здесь можно не так" и поддерживать некоторую гомогенность системы, я бы все сделал через readonly + метод.
Вы требования их сервера синхронизации видели? Если не видели - посмотрите.
Это даже не стрельба гаубицей по воробьям - там можно целый сервис высокнагруженного бизнеса на этом решении организовать, а не то что файл конфигурации синхронизировать.
Расскажите это SQLlite-у, который, собственно, в Mozilla-вских продуктах широко используется.
Достаточно положить один файл SQLite, и выполнять синхронизацию от любого кол-ва устройств.
Да и, честно, вообще проблем сделать это хоть с одним файлом с JSON ни каких нет - с помощью блокировок все это решаемо. Конфликт может быть только при обновлении.
При синхронизации заблокировал (остальные ждут освобождения), синхронизировал, разблокировал - все - будет работать вполне нормально, без каких-либо конфликтов.
Как сделать сигнал блокировки - можно атрибутами файла, переименовыванием, созданием лок-файла рядом - вариантов также масса.
Есть только один риск - если приложение упало не разблокировав файл - решается временной меткой файла - если с момента блокировки прошло достаточно много врмени, форсить разблокировку-блокировку.
Чтобы было подобие транзакционности и избежать неконсистентности делают так: блокируют основной файл, пишут файл рядом, переименовывают записанный файл в основной файл, снимают блокировку. Это обеспечивает консистентность.
Я, как раз, разбирался - и то, что там предлагают - нормально не юзабельно. Я решил это проблему самописным экстеншеном (синхронизация закладок/открытых вкладок - мне больше ничего не надо), но да - с бд на своем собственном сервере, так как она уже там была. Мог сделать и через один файл.
Прежде чем навшивать ярлыки на собеседника, может быть стоило поинтересоваться его опытом?
Mozilla всё :(
А если серьезно - то задолбали бесполезные изменения аля "нововведения" и попытки затащить пользователей к себе.
Понятно почему очень хочется, но хотя-бы в одной альтернативе могли этого не делать или сделать возможность сторить данные в виде одного файла по указанной ссылке - тогда это можно было класть это куда угодно - хочешь - к ним на сервер, хочешь - в дропбокс, хочешь - к себе на vds.
О, дивный новый мир!
Конечно, технология виновата, а не сами люди. Это-ж технология подкладывает себя людям в игрушки!
А ещё надо запретить жпс-трекеры, сотовые телефоны и фонарики!
Apple недостаточно информирует о технологиях, научные журналы вообще охренели - ничего не понятно, а у людей лапки!!!
Вчера, выходя из бара асфальт стал пониматься и бить поситителей по голове! Нужно, чтобы дорожные службы информировали поситителей, что нельзя так бухать!
Как жииить?!!
Кроме просто написания, это нужно еще продумать.
Компилятор следит за верностью использования, а не за бизнес-логикой, "следить" в этом случае - это использовать согласно задаче, а не в плане правильно/неправильно
Нет, само оно только подсказывает типы, если они уже написаны, никто за вас автоматом типы в функцию или класс, который еще не написан, как и его составлюящие, не подставит, если он состоит из новых сущностей.
Т.е. программирование таки разделяется на две вещи, как я уже выше писал - создание/изменение типов там где нужно, и сама программа, это использующая , для решения задачи бизнеса.
Грубо говоря, если вам надо описать что-то из чего-то - вы вынуждены будете описать тип того, что хотите в контейнер пооложить, а потом объявить контейнер соответствующего типа. Никто за вас это не сделает. В языка со слабой типизацией вы просто объявили контейнер и кладете туда все что хотите.
И еще раз - мой посыл не в том, что слабая или сильная типизация плохи или хороши, а в том, что они дают разные преимущества.
Оттуда, что не надо описывать дополнительно типы, следить за ними и их использованием.
Кроме того, когда пишешь фии и еще неизвестно что она должна возвращать (POC например) - с этим тоже можно не заморачиваться и дописать позже и тд.
Вобщем как раз из-за того, что при использовании типов ты как бы два рилма в голове держишь - рилм кода бизнес-логики и рилм типов, этот код обслуживающий.
Надеюсь понятно изложил.
Молоток - очень крутая штука, я реально не понимаю людей, которые используют отвертку! Ведь молотком можно и гвозь забивать и шуруп!
Очередная статья из серии "Кто сильнее Акула или Медведь?".
Это все - инструменты. Умение их использовать открывает вам соответсвующие двери и наоборот.
Правильно настроенный линтер на языке со слабой типизацией сводит практически все описанные ошибки на нет. Скорость разработки POCов или каких-либо конверторов данных для разовых операций идет гораздо быстрее на языках со слабой типизацией - один из сильных вариантов их использования.
Тяжелый проект, сторящийся на века и поддерживаемый командой - да, нужно писать с типизацией - на дает соотвествующую выгоду, расплата за это - время написания кода.
Вот и все - но нет, опять появляются остроконечники vs тупоконечники.
Еще раз - языки - это инструменты, универсального нет - выбирая один, ты всегда в чем-то выигрываешь, а в чем-то проигрываешь.
БОЖЕ!!! Какой ужас! </sarcasm
Справедливости ради, быковать начал как раз другой партнер.
Доказательство чипов-шпионов и тд так и не предоставили. Ну и тп.
Это вовсе не означает, что КНР белый и пушистый, но то, что он сделал и почему - как раз не связано с их быкованием - они достаточно честно себе вели с партнерами, чего не сказать про них. Их мотивы тоже понятны, но вот поведение - не очень.
Ну и не надо китайцев за дураков деражть - они прекрасно мониторят рынок и в случае появления "конкурентов" будет работать старая добрая схема с демпингом.
С Галлием не все так просто.
От оно что! А че не трутовик?)))
Те господа импортозамещатели даже не в курсе, что в разных языках слова могут иметь разные оттенки смысла и переводить их "в лоб" не очень хорошо.
P. S. емнип создатели его так назвали держа в голове как раз слэнговый оттенок, который можно на русский грубо перевести так "из искры возгорится пламя", фитиль тут не причём, скорее больше подходит русское слово "растопка", ну или "дрова". То, что понимают у нас под словом "фитиль" проводится на английский как wick. Именно по-этому у меня даже асссоциаций не возникало.
Вот и назвали бы свой сервис "Искра" — оно по смыслy как раз бьется с оттенком слова tinder + на русском есть оттенок этого слова в плане отношений.
Ну или "Фертиль" — было бы по делу, с юмором, отсылкой и на французский манер)
Ответьте пожалуйста на один вопрос — доколе это будет на Хабре? Каждый пост минусуют — вам это ни о чем не говорит?
Попытки высосать техническую составляющую из пальца (или откуда там у вас) в статье выглядят смешно и нелепо.
Одно только ваше название вызывает у людей чуть постарше ассоциацию с одним очень интересным, но далёким от знакомств, журналом — и из-за диссонанса это вызывает раздражение, а помладше даже слова такого не знают, что, в принципе, вполне нормально. Страшно подумать, откуда оно взялось для такого сервиса. У меня только старый анекдот напрашивается про дядьку с животом в бане, бомбу, двух ребятишек и короткий фитиль…
Кроме того, в силу некоторых обстоятельств (которые ведомы большинству, но почему-то неведомы тем, кто пытается "предоставлять" услуги на данном поле) на всех подобных сервисах знакомств всегда много М и очень мало Ж, однако вы упорно пытаетесь постить статьи на ресурсе с точно таким-же перекосом.
Я даже и не знаю, что вам сказать после этого…
ИМХО регистрироваться у вас при таком подходе точно не надо.
Про режим флешки я как раз ничего и не писал)
Я, если честно, не понял, зачем нужно SWO/VCP в программаторе?
Т.к. любая (ну или почти любая ) ножка процессора элементарно превращается в UART либо что-либо еще аппаратно, либо битбэнгом - и выводит или вводит все, что душе угодно.
Вирутальный COM? - да вообще без проблем - цепляешь UART к UART2USB с али за 1$ и все - можно отправлять/принимать что угодно, мало того, их можно присоеденить не один, а несколько к разным ножкам и гнать телеметрию по всем ним.
Причем тут программатор?
Ну или я не понимаю чего-то.
В win10 эта настройка не работает — окна на панели управления продолжают перетаскиваться скопом, если это одна и таже программа, это очень старый баг.
Те стандартными средствами добиться нормального поведения невозможно.
Баг этот был найден давным-давно и находится в exolorer-e или каком-то его компоненте, который и патчится в рантайме сторонними программами и до сих пор так и не прфикшена, как и проблема с тенями с подписями иконок рабочего стола.
Там все более менее, спасибо вашим статьям, там проблема в другом — практически все браузеры сейчас "заботятся о безопасности" и не дают сохранять файлы локально. Те прочесть не сложно, а вот сохранить.
А возможно сделать одно из устройств виртуальной сетевой картой?
Ибо настраивать параметры через вебинтерфейс очень было бы удобно.
Пока пытаюсь сделать msd, при сохранении на которой конфиг парсится и уходит в контроллер.
Вы мои комментарии выше перечитайте еще раз - у меня где-то что-то написано про фреймворк? Речь про данные, а не про фреймворки - когда получится это осилить - можно будет продолжать разговор.
Еще раз - проблемы возникают не из-за фреймворка, а из-за множественных источников изменения. От фреймворка в данном случае ничего не зависит, можно и во Vue, если очень хочется, изменять пропс (через функцию, например).
Но потом отлавливать где же что установило некорректное значение, и почему появилась петля в данных будет вашим личным адом.
А причем тут Vue? Речь про направление потока данных.
В Vue можно писать и без пропсов - если очень хочется, с использованием чего-либо другого для данных - стора, шин, прокси и т.д.
Но если хочется использовать пропсы - то лучше придерживаться однонаправленого потока данных, в каком бы фреймворке это не происходило.
В минимзации всего и вся - обращений к бэку, размера этих обращений, рендеринга, их дебаунс и объединение + универсализации компонент и фронта в целом (из-за огромной фрагментации устройств, с которых сидят пользователи) и тд.
Объяснять это в комментарии долго - это тема целых докладов на хайлоадах.
Есть огромная пропасть между приложениями на десятки пользователей и на десятки тысяч на фронте. Про бэк я вообще молчу.