У меня глупый вопрос. Если мы возьмём тот же nanoevents. Где мы будем создавать новый eventemitter и подписываться на события? В компоненте, в файле api.js или в отдельном файле?
Ну насколько я понял и сумел систематизировать - выносим все что не изменяет состояние компонента напрямую в сервис-фасад, который содержит в себе микросервисы, решающие более узкие задачи - работа с АПИ, обработка данных... И через этот сервис фасад юзаем весь нужный функционал
single responsibility и разбивка на все эти слои решает только 1 проблему? мы это делаем что бы не хранить это все в одном файлике и соответственно что бы была лучшая навигация по коду? я пытаюсь понять что будет если я не буду следовать single responsibility?
я тоже пытаюсь понять, но никак не пойму) все что тут звучит мне кажется абстракцией, которую сложно уловить. вью - занимается отображением данных и управлением, но если встречается то, что не попадает под эту категорию, значит надо выносить в отдельную сущность. так по мне что, было до этого все в одном файле, что сейчас в двух файлах - все одна каша, из которой я не получаю никакой значимой выгоды в рамках текущей задачи. единственное - так это очень плохо навигировать в коде, и его рефакторить - так как реально там сплошная каша. вот смысл который я смог увидеть в разбиении кода и вынесении разной функциональности
Как же мне нравятся эти дурацкие карандашики с блестками и космосом, прям гипнотизируют.
Следующее видео 16.03.2021 в 22:00 по Украине
спасибо большое=))
У меня глупый вопрос.
Если мы возьмём тот же nanoevents. Где мы будем создавать новый eventemitter и подписываться на события? В компоненте, в файле api.js или в отдельном файле?
Кому он нужен? emitter нужен api - наше приложение хочет пользоваться апи и ничего не знать об эмиттере. Вот апи и будет создавать
Ну насколько я понял и сумел систематизировать - выносим все что не изменяет состояние компонента напрямую в сервис-фасад, который содержит в себе микросервисы, решающие более узкие задачи - работа с АПИ, обработка данных... И через этот сервис фасад юзаем весь нужный функционал
single responsibility и разбивка на все эти слои решает только 1 проблему? мы это делаем что бы не хранить это все в одном файлике и соответственно что бы была лучшая навигация по коду? я пытаюсь понять что будет если я не буду следовать single responsibility?
я тоже пытаюсь понять, но никак не пойму) все что тут звучит мне кажется абстракцией, которую сложно уловить. вью - занимается отображением данных и управлением, но если встречается то, что не попадает под эту категорию, значит надо выносить в отдельную сущность. так по мне что, было до этого все в одном файле, что сейчас в двух файлах - все одна каша, из которой я не получаю никакой значимой выгоды в рамках текущей задачи. единственное - так это очень плохо навигировать в коде, и его рефакторить - так как реально там сплошная каша. вот смысл который я смог увидеть в разбиении кода и вынесении разной функциональности
8:17 Вы уверены, что Эйнштейн так говорил? Только ситхи всё возводят в абсолют =D
Про "всё относительно" он точно говорил =D
@@JavaScriptNinja Тогда можно, пожалуйста, ссылку на источник? Среди его цитат я не могу найти такую. А в поиске на эту тему только какие-то анекдоты.
@@ilyachistyakov47 Владилен, перелогиньтесь.
@@1tsv1kt0r )))
@@ilyachistyakov47 Владилен, перелогиньтесь.
Это вам не Владилен... в хорошем смысле
а что не так с человеком, названным в честь Ильича?:)
@@____Olga__ он говорит куда копать, но не говорит почему. Илья объясняет почему копать, как копать и чем копать (в 80% случаев!).
Отстаньте уже от человека:) Пусть будет много разного контента. Каждый выберет под свой уровень
Один Владилен поставил диз