Со вторым примером не смог разобраться, но если он делает то же самое, что и первый, то штука абсолютно бесполезная. Определяет, что я из Москвы. Из самого кремля. Я километров 40 от него.
Доступ к гео имеют все приложения, которым это необходимо для работы. Вроде такси или доставки. У меня больше сотни приложений, если вы подскажете, как вам предоставить список их разрешений, я это сделаю :)
Да, номер телефона зарегистрирован на меня, но прописан я в другом месте, плюс моя вторая квартира, в которой я 2-3 месяца живу, вообще никак ко мне не привязана по документам. Тем не менее, вк знает даже подъезд дома.
Если вы — ФСБ, то вы может быть и можете определить по вышкам моё местоположение. Но в данном случае речь идёт о коммерческой организации. Откуда у них такие доступы?
И делится ли IOS названиями Wi-Fi сетей?
И всё-таки, тогда как обозвать используемый мной подход?
Практика-то довольно распространённая. Есть несколько бэкендеров, у них разная зона ответственности, поэтому они на каждую предметную область заводят свой репозиторий, используя при этом одну БД.
У этого же есть какое-то название? Почему это не может быть микросервисом?
Обязательно ли микросервису иметь выделенную БД, что бы называться микросервисом? Если у меня два, как я их называю, микросервиса, используют одну БД, то как они называются?
К примеру, один из них отвечает за регистрацию/авторизацию, а другой за обработку платежей
Я пробовал использовать его в идее, но что бы использовать хоткеи для рефакторинга, приходится зажимать дополнительно клавишу fn. Подскажете, как пофиксить это?
Из моего опыта разработки клиентской части, что в геймдеве, что в вебе данные удобнее хранить в одном месте (классе) и не писать там больше дополнительного функционала, кроме самого основного (отписки/подписки)
А можно конкретные примеры — почему удобнее? Чем централизованное хранилище лучше децентрализованного, разбитого на модули?
К примеру, наш FriendsService подписан на socket событие friends:state, в котором прилетает состояние списка. Мы стоим перед выбором — записать список в глобальный стор, либо в this.state.
Почему мы должны выбрать глобальный стор для этой цели?
Также интересует вопрос — как быть, если приложение разделено на изолированные модули, подгружаемые с помощью LazyLoading? Только что загруженный модуль должен использовать глобальное состояние для хранения своих данных?
Я уже который год пытаюсь осознать смысл Redux. После прочтения вашей статьи мои сомнения в нём только усугубились.
1) Почему мы не можем хранить состояние списка друзей в синглтоне FriendsService? При таком подходе данные всегда будут синхронизированы во всех компонентах, использующих список друзей.
2) Почему запросом данных и передачей их в хранилище занимается компонент списка друзей? Что, если у нас два компонента для рендеринга этого списка — один в разделе «Мои друзья», другой в модальном окне «Поделиться записью», выглядят совершенно по-разному. Каждый компонент должен проверять наличие данных в состоянии, и грузить их, если они отсутствуют? Дублирование кода же.
3) У нас же real-time приложение. По сокетам прилетает событие, мол, новый друг добавлен в список, или удалён из него. Где это обрабатывать? Самый логичный вариант — этим должен заниматься тот самый синглтон FriendsService.
В чём преимущество Redux перед описанным мной подходом?
Кто-нибудь, пожалуйста, ответьте мне на эти вопросы. Я чувствую себя неполноценным членом Front-end сообщества из-за непринятия Redux.
Я как-раз во второй части статьи перестал понимать, что происходит, из-за минификации. Действительно, лучше приводить полный, читаемый код, но количество символов в нём учитывать уже после минификации, раз уж статья для читателя, а не js-интерпретатора :)
Да с чего вы взяли-то, что они неправильные?! Вы бы прежде, чем на хабр писать такие вещи, поинтересовались бы, что это за кавычки такие.
Это template strings developer.mozilla.org/ru/docs/Web/JavaScript/Reference/template_strings
Код, указанный в данном разделе теста, абсолютно валиден.
Да, номер телефона зарегистрирован на меня, но прописан я в другом месте, плюс моя вторая квартира, в которой я 2-3 месяца живу, вообще никак ко мне не привязана по документам. Тем не менее, вк знает даже подъезд дома.
И делится ли IOS названиями Wi-Fi сетей?
Практика-то довольно распространённая. Есть несколько бэкендеров, у них разная зона ответственности, поэтому они на каждую предметную область заводят свой репозиторий, используя при этом одну БД.
У этого же есть какое-то название? Почему это не может быть микросервисом?
К примеру, один из них отвечает за регистрацию/авторизацию, а другой за обработку платежей
А можно конкретные примеры — почему удобнее? Чем централизованное хранилище лучше децентрализованного, разбитого на модули?
К примеру, наш FriendsService подписан на socket событие friends:state, в котором прилетает состояние списка. Мы стоим перед выбором — записать список в глобальный стор, либо в this.state.
Почему мы должны выбрать глобальный стор для этой цели?
Также интересует вопрос — как быть, если приложение разделено на изолированные модули, подгружаемые с помощью LazyLoading? Только что загруженный модуль должен использовать глобальное состояние для хранения своих данных?
1) Почему мы не можем хранить состояние списка друзей в синглтоне FriendsService? При таком подходе данные всегда будут синхронизированы во всех компонентах, использующих список друзей.
2) Почему запросом данных и передачей их в хранилище занимается компонент списка друзей? Что, если у нас два компонента для рендеринга этого списка — один в разделе «Мои друзья», другой в модальном окне «Поделиться записью», выглядят совершенно по-разному. Каждый компонент должен проверять наличие данных в состоянии, и грузить их, если они отсутствуют? Дублирование кода же.
3) У нас же real-time приложение. По сокетам прилетает событие, мол, новый друг добавлен в список, или удалён из него. Где это обрабатывать? Самый логичный вариант — этим должен заниматься тот самый синглтон FriendsService.
В чём преимущество Redux перед описанным мной подходом?
Кто-нибудь, пожалуйста, ответьте мне на эти вопросы. Я чувствую себя неполноценным членом Front-end сообщества из-за непринятия Redux.
Это template strings
developer.mozilla.org/ru/docs/Web/JavaScript/Reference/template_strings
Код, указанный в данном разделе теста, абсолютно валиден.