Как правильно реализовать паттерн MVC?

Сергей Протько: сказал Вам чтобы попробовали, а для чего так и не договорил. Когда Вы сделаете правильное приложение с правильной моделью, такое что его можно будет легко портировать на все фраймворки, Вы поймете что такое модели и что к ней вообще не относится. И только тогда Вы поймете что то что сегодня Вы понимаете как не представление на самом деле является сложным состовным представлением. Вы должны понять что компонент TextArea не имеет модель со значением text, а объект который хранит строку является такой же частью представления. И что то же redux это всего-лишь библиотека для работы с представлением.

Как правильно реализовать паттерн MVC?

Сергей Протько: забыл Вас упомянуть, текст выше.

Как правильно реализовать паттерн MVC?

Этот протокол подразумевает возможность построения такой цепочки адаптеров или мидлвэров если хотите.

Ну мне кажется не стоит упоминать о промежуточных архитектурных решениях в контексте mvc, это только запутывает. то есть посудите сами, когда говорят о mvc подразумеваю разделение логики от отображения. А начиная перечислять все подряд и размыливая до service или adapter или decorator, согласитесь, не айс вообще. То есть все кроме mvc, это промежуточные решения о которых не стоит говорить в контексте mvc. Это приводит к запутыванию, которое пугает людей.

Вот только сегодня рассуждал над проблемой непонимания ооп и мне кажется нашел причину и она та же что у mvc. Вот смотрите сами, я пишу приложение и использую самописное mvc что Выливается в несколько файлов даже на java. Все очень просто нет лишних медиаторов, проксей, декораторов и прочих паттернов, которые могут быть полезны при написании большого приложения. И вот я гордый что смог написать pure mvc, решил его закатать в фраймворк. И тут пришел кто-то и говорит что он столкнулся с ситуацией, когда нужны медиаторы. А другому понадобились прокси и декораторы, мосты, конечные автоматы, спецификация. А потом ещё и ещё стали приходить и просить добавить модели в виде коллекций и чтобы они json заправлялись.
И в итоге получился шатл. Теперь он долек от первоначальной затеи, но зато все угождает.
А что же я буду делать потом? Конечно писать мануалы и уроки, но не просто так, а заранее составлю пункты всех уроков и придумаю такое минимально приложение чтобы охватить все.
и в итоге получится хелловорлд с медиаторами и прочими сложностями которое я подам как спасение. Вот только я очень умный и забыл что когда-то был человеком, который после прочтения книги сел и пол дня не знал что тыкнуть чтобы что-то вывести на экран. и я забыл сказать что все это нужно применять только тогда, когда это действительно надо.
И вот значит пришли новички и решили что все эти тысячи медиаторов и прочего нужно писать всегда. Но естественно они усомнились, как и во всме по началу и пошли спрашивать у умных дедей, которые на вопрос - "а правильно ли использовать все это в контексте ооп" ответи "ДА", ведь оно так и есть, но только в нужные моменты. ооп это как витамины которые нужно принимать только в нужное время иначе пользы не будет. Но что Вы ответите если Вас спросят "нужно ли принимать витамины?", конечно "да!".
И вот как мне кажется, да оно так и есть, это понятно по тому что прежде всего ооп ругают за сложность и избыточность, в то время как все это вызвано банальной-глобальной человеческой ошибкой заключающийся в том, что все мы забываем что были когда-то глупыми не такими как сейчас. Да и занятость делает свое дело и вместо миллиона слов проще сказать что "да".

Вот так же и с mvc - гуру тостера сказал что на сервере не может быть правильного mvc из-за того что не делает те приложения, которые просто обязаны быть реализованными по правильному mvc иначе исполнители столкнуться со сложностями и будут потом говорить что mvc это фигня и они на собственном опыте изобрели что-то вроде mmvcmps. А на деле они из mvp сделали не до mvc.

Когда мы обсуждаем паттер конечные автоматы мы не будем обсуждать паттерн стратегия.
Почему когда мы обсуждаем mvc мы упоминаем адаптер?

Не говоря уже что на сегодняшний день делать активные вьюшки - избыточно. Потому то почти все используют вариации MVP/MVVM/MVA.

Вы опять не правы. сегодня как никогда раньше используют активные вьюшки. Это раньше их не использовали, а сегодня все больше и больше приближаются к классике. И Вы этого не понимаете из-за того что не хотите признать что не понимаете mvc. Я не буду раздувать опять эту тему, это бесполезно пока Вы не начнете писать игры или сложные приложения не обязательно десктопные, сейчас уже вэб от них не отличить. Все что сегодня Вам выдают за модель является представлением, сложным, но представлением.

и это приучает разработчиков делать много маленьких объектов а не дебильные классы менеджеры.

Я некоторое время назад хихикал над Вами когда Вы все в сервисы закручивали, а сегодня АДАПТЕРЫ :) Так можно вообще создать просто А адаптеры и все в них нафигачивать и тоже получится.

Лично я тоже все больше склоняюсь к простому, нежели раньше мечтал усложнить. Но когда делаю нестандартные вещи, то очень часто из-за легкости встреваю в тупик и приходится все откатывать и делать сложно и правильно.

Вам совет, сделайте игру с активной моделью и чтобы эту игру можно было с легкостью на разные фраймворки портировать. или подумайте хотя бы над этим. Как бы Вы сделали игру если бы в ТЗ входило что она-игра-(модель игры) легко реализовываться на любом из современных фраймворках. понимаете, модель приложения, это как двигатель в авто, который будет работать независимо от остальной части и не важно к чему его прикрутят. И все-таки лучше сделать чтобы на лицо увидеть что должно быть в модели, а что нет. Мне кажется Вы очень удивитесь. И если вас игры не привлекают, то поймите что точно так же будут писаться и другие сложные приложения не являющимися сайтами, а как например онлайн 3d редакторы, которыми я жутко увлёкся и вообще погрузился в 3d и делаю как раз первую 3d игру. И оказывается что даже моделировать у меня чуть-чуть получается. И как раз польза для будущего, так как делаю её на webgl.

Что от меня хотят?

функция, это объект, который содержит ссылки на два другие объекта this и prototype.
то есть можно представить это в виде -

var function = {
   this: {},
   prototype: {}
};

и когда Вы в конструкторе создали переменную name, то положили её в объект this.
Так же Вы прототипе объекта (у меня function у вас Person) создали свойство ссылающее на функцию greet и теперь эта функция считается методом объекта Person. то есть когда просто где-то то это функция, когда у чего-то, в даном случаи у объекта, то это метод. А дальше в методе greet Вы обращаетесь к свойству (кстати когда переменная не имеет контекста, то это переменная, а когда имеет, как в данном случаи name объявлена в контексте this, то она становится свойством объекта) name, то есть к name объявленному в конструкторе.

Стоит также упомянуть что убрав метода greet его контекст выбросится исключения, так как контекста this со свойство name уже не будет.

Как именно работают drag события?

Worddoc: в реальном мире никто не использует нативные события драга, вместо этого пишут свою реализацию. По ссылке не ходил, но если это именно та статья о которой я думаю, то она очень пригодная и правильная и отвечает на все вопросы. Мне было бы не сложно объяснить как делаю именно я, но это было бы в 90% так же как и в статье ссылку на которою Вам дали. И ещё там кажется не одна подобная статья, а целый раздел посвященный драгу. так же на этом ресурсе есть самые лучшие в интернете статьи которые рассказывают о позиционировании дом элементов. Я во многих языках писал драг и когда перешел на вэб то сам читал этот захватывающий учебник. Вам искренне советую.

React. Server rendering. Видел ли кто-то адекватную реализацию fetchData? (т.е. с загрузкой асинхронных данных)?

Антон Жуков: хотя я ошибся из-за того что начал думать как Вы! Данные хранятся в сторе и когда он обновляется то сообщает компоненту что нужно обновить данные, а компонент при обновлении рендерится. На клиенте Вы передаете стор сразу и рендер происходит этапами, рендер (пустой) -> загрузка завершена -> рендер с данными.
А на сервере Вам первым делом Вам нужно инициировать загрузку и по её окончанию передать уже полный стор в App и рендереить. То есть приложение от этого никак не меняется, меняется лишь способ инициализации.

React. Server rendering. Видел ли кто-то адекватную реализацию fetchData? (т.е. с загрузкой асинхронных данных)?

Антон Жуков: Вы хотите самолет и думаете что если сядите за штурвал, то сразу станете асом? Вот так же и реакт никакого отношения к загрузке не имеет. В даете ему данные он их преобразовывает в html. Хотите по другому, делайте свой фраймворк.

Как правильно реализовать паттерн MVC?

Сергей Протько: ну mvc 79 это -> m -> v -> c -> и вот как раз это mvc очень просто использовать и в вэбе. Ведь кто Вам запрещает серверную чать atom перенести на удаленный сервер и конектится к нему из обычного браузера. Или вот любые игры на php тоже дело распространенное и это тоже вэб и самое главное что желание написать правильно должно привести к mvc 79, а если кто-то скажет что он может по другому как-то сделать, то все что угодно можно сделать, только вот это не будет правильно.

Да ну 90% включаю опытных разработчиков и то наверное не понимают для чего им mvc и ему подобные архитектурные решения, это нормально. Главное понять ПРЕДНАЗНАЧЕНИЕ и тогда будет понятно что контроллер с точки зрения mvc и с точки зрения ооп должен быть только контроллером и знать только то что он контроллер.
Он должен иметь знания как работать с моделью и представлением и ничего не знать о каких-то валидаторах и прочей ерунде, которыми уже декорируют путь от контроллера к чему-то или от роутера к контроллеру.

Как правильно реализовать паттерн MVC?

Fedor: Вы описали mvp.

Как правильно реализовать паттерн MVC?

MVC 79-ого года на бэкэнде не применим.

Каждый раз ваши ответы становятся все более пугающее, такое ощущение что Вы честно пытаетесь во всем разобраться, но от обильного потока данных запутались.
Игровой сервер, сервер какого-то ПО, например visual code или atom с могут и должны быть реализованы по mvc. И уже пора начать расставлять все точки и смело говорить что для обычных приложений на сервере используют не mvc, а mvp где баллом правит контроллер делая выборки из модели передает их в представление. Правда контроллер назван Презентер, но у меня сложилась привычка и я всегда называю его контроллером.

Как вернуть Promise из нескольких последовательных асинхронных вызовов?

Если сама mongo не возвращает промис, то лучше всего создавать цепочку из самих промисов передающих результат по цепочке.

Какими способами можно получить аргументы из консоли в typescript?

Bowen: ну как минимум не будите как лох писать референсы...

Какими способами можно получить аргументы из консоли в typescript?

А почему Вы декларации не хотите добавлять через конфиг typescript, как это делают все?

Почему не удаляется свойство объекта?

Nikita Schipilov: не понял?

Почему не удаляется свойство объекта?

Алексей Уколов: почему бессмыслица, у Function есть свойство name которое возврыщает имя самой функции https://developer.mozilla.org/ru/docs/Web/JavaScri...

А автор просто не ещё не знает что this это совсем не тот же объект что Foo, типично для новичка.

Почему не удаляется свойство объекта?

Алексей Уколов: а Func.prototype.name тут не причем, автор даже не упоминал prototype.
Автор удаляет Func.name что является именем самой функции, то есть Foo.

Как реализовать ротацию на JS?

Serdji: для начала нужно определить что есть 100%, пусть это будет сто подключений. Самый простой способ продолжить, это создать массив у которого 90 элементов будут 1, а десь 0.
Осталось определиться как будет действовать рандом для каждого по отдельности или для всех общий. Если для каждого по отдельности то можно записыать этот массив в localStorage клиенту в худшем случаи, а в лучшем в его профиль в БД. Если же один рандом для всех, то работать с массивом только на сервере, по другому не получится. А работа простая, кто-то подключился взял и удалил последний элемент и если значение 1 то вызываем что-то, 0 то что=то другое. Когда массив закончится, то набить его заного цифрами и рандомно перемешать.

Стоит ли создавать дополнительные переменные для лучшей читаемости кода?

В большинстве случаев у Вас это должно происходить само сабой, то есть - User.fullName = user.lastName + user.secondName; Другими словами в 98% кода Вы должны "жонглировать" объектами.

Ну а в остальных случаев лично я за создание переменной которая говорит то что она делает.
Вы должны писать код, который будет понятен всем без комментариев. И не забывайте придерживаться конвенций языка на котором пишите.

Но в конкретном примере я за второй вариант, если как сказали ниже Вы не обращаетесь к переменной массива несколько раз.

Как правильно войти в индустрию разработки игр?

игрострой стоит как минимум на трех китах - программирование, физмат, цифровое изо.
поэтому чтобы называть себя причастным к игрострою нужно иметь как минимум минимальные познания во всех трех направлениях. Первый пункт в гемдеве очень важен, так как просто знать и уметь писать код без хелпа недостаточно, обязательно нужно знать принципы и ооп и уметь применять шаблоны в тех или иных ситуациях, писать очень понятный и легко масштабируемый код.
Если не знать как устроена механика реального мира, то Вы не сможете повторить её даже с самым продвинутым физическим движком. Это намек что второй пункт не менее важен чем первый. Тем более что уметь реализовывать различные нестандартные алгоритмы, которые принесут в Вашу игру изюминку, большой плюс.
Третье это не только шейдеры без которых просто никуда, но ещё и понимания процесса рендера, нарушь который хоть чуть-чуть и самые красивые ассеты превратятся в омерзительно фонящие убожества. Ну и теорию цвета тоже нужно почитать.

И ещё сетевое взаимодействие для мультиплеерных игр. Это как мне кажется для джуна минимум. Просто я не думаю что Вы кому-то будите экономически выгодны без знания всего этого.

Передача значения из одного компонента в другой, ReactJs?

Тут с какой стороны смотреть.. Если цвет неизменен и задается через js, то можно его значение вынести в специальный объект с константами. И вот если для себя и маленькое приложение пишешь и все пофигу, то можно и прям в компоненте к нему обращаться. Если же хочется "правильности", то передаешь значение этого цвета в компонент там, где его инициализируешь.

И если можно все сделать стилями, то нужно делать стилями. Если не получается, то уже через js. А способов много, от обычного js и до css modules.