PxlFxr, Вы хотите к тексту подокапываться с умным видом или расспросить детали и что-то новое узнать?
Если подокапываться - то без меня, не согласны, расскажите как оно все на самом деле, подробно, понятно, чтобы было полезно.
Если что-то новое узнать, то непохоже.
В любом планировщике будут разные мелкие различия, если вам так важны какие-то мелочи, то для вас один путь - пробовать все подряд и выбирать. За вас это никто не сделает.
profcat, Это подходы были придуманы для вполне конкретных архитектур и задач, где они решали вполне конкретные проблемы.
В современных веб приложениях многое устроено совсем по другому. И поменялось уже настолько что попытка привнести "правильный" MV* паттерн туда где уже нет тех проблем и ограничений, для которых они создавались, нет такой же структуры, по большей части создаст просто лишний код и ненужную сложность, без какой-то явной пользы.
Можно конечно говорить о частичной реализации какого-то паттерна, вот с такими оговорками, вот такими изменениями, и вот этот термин будет теперь значить не то что он значит а другое. Но это если сильно хочется сказать что какой-то паттерн как бы есть, на самом деле, паттерн - это шаблон, либо вы делаете по нему, или признайтесь что делаете что-то другое.
Общие какие-то моменты все равно будут потому что в любом приложении же есть данные, логика и представление данных, это никуда не делось, но никаких MV* паттернов в реакт приложениях никто не реализует.
Даже если слой реакт-компонентов назвать View, то без M* это будет что-то другое.
все MV* можно грубо назвать способами связать M и V.
Если это C - то у вас должен быть контроллер в явном виде. Если у вас какой-то код где-то выполняет некоторые функции контроллера, то это все равно не контроллер.
Если это P или VM то же самое.
Если вы это вкорячите в реакт "по правильному" то с большой вероятностью будет гора костылей.
Моделей в классическом их виде в реакт приложениях тоже не пишут. Можно но незачем.
И в целом разделение другое - отдельно данные, отдельно логика данных, отдельно представление.
Логика представления либо в самих компонентах, если она локальная, либо где-то еще (редьюсеры, экшены, сервисы) если она глобальная. Сейчас уже и логику представления от самого представления начали отделять (привет хуки!).
Так что можете назвать приложения на реакте написанными с использованием паттерна V*
Есть View, который реализует реакт и куча способов как построить остальное приложение. Там ООП, функциональщина, реактивность, синглтоны, очень-умный-удаленный-стейт, магические байндинги и прочее. Кто что придумает, в меру своих способностей и используемых библиотек для реализации логики - данных и их подходов.
Но какого-то "паттерна" такого же устоявшегося и известного как MV* нет.
Что-то из MV* можно построить и на реакте. Но этого не делают не потому что никто не осилил, а потому что это не нужно, усилий много, пользы меньше чем вреда.
Для академического интереса можете реализовать их все. Соберете пару лайков.
А потом обратно на работу писать код в том виде в каком это более быстро, удобно и эффективно.
Владимир, "Правильный ответ" это отвечать на вопрос который был задан, что я и сделал. Конкретно мой ответ относился к конкретному вопросу и этот вопрос совершенно не про реакт - перечитайте тред еще раз.
Kizzeon, ну, моя цифра от балды такая, ваша цифра от балды такая.
Не вижу что тут обсуждать. обе цифры крайне далеки от представлений автора что "в браузере JS уже никто не запускает".
Или у вас есть какие-то фактические серьезные исследования доли приложений с SSR против всех веб-приложений? с удовольствием почитаю
Я не очень понимаю о чем вы тут говорите. Дефолтное значение есть всегода, в первом случае это undefined, во втором - пустой массив. Какое вам подойдет, решаете вы, а не реакт.
Если вы делаете `nav.map`, то очевидно что у вас массив должен быть всегда, если вы туда положите undefined оно просто упадет.
Это все никак не связано с вызовом setNav, который у вас как не работал, так и не должен работать. Читайте про промисы, async/await.
Это ломает вас а не TS.
Нет никакой сложности писать типы сразу, если вы владеетет языком, то это быстрее и эффективнее. А вы видимо не только не владеете, но еще и не хотите изучать, и пишете посты в духе "я написал кривой код и получил ошибку, пришлось вырубить компилятор, тайпскрипт-говно".
Бедный лид. Саботировать проект вы уже начали, или пока просто в интернете пар выпускаете?
johand, кондер вам не создает свежий воздух. Если вы сидите в тропиках в законопаченном помещении с кондером, то вентиляцию вам надо сделать в первую очередь.
Сергей Стадник, читаете файл, достаете оттуда все настройки, для каждой вызываете update.hear.
По аналогии - если вам надо вывести набор строк в консоль, можно сделать 10 строчек в духе
console.log('aee')
console.log('123')
...
и так далее,
И для новой строки каждый раз добавляя код в main.js
а можно сделать и по другому. чтобы добавлятьновые строки не меняя main.js Как именно - придумайте.
как придумаете - поймете как вашу задачу лучше сделать
Сергей Ракипов, ну раз он "не лучше" - то вот вам и ответ почему им никто не пользуется - зачем на него переходить с других, популярных редакторов, если плюсов не будет? незачем.
почему другие стали популярны а дримвивер канул в небытие - это отдельный вопрос, больше исторический. Просто примите это как факт.
насчет визуального редактора - уже многие годы индустриальный стандарт - лайв-хот релоад, вы пишете в редакторе, причем в любом и сразу видите как это выглядит в реальном браузере со всеми его глюками и погремушками. У этого, помимо реального браузера, куча других плюсов, например это будет работать у всех в команде, независимо от того что у них за редакторы.
Manjuri, Это вопрос в первую очередь общения со сбербанком, тут я вам помочь не могу. Если решение есть - договаривайтесь или ищите того кто может договориться.
Сама технология достаточно простая. Для вас это вообще будет "вызвать сервер сбербанка, получить от него ссылку".
Сергей Ракипов, ну например размер и тормоза уже достаточная причина. Ну и изначально он был заточен под визуальное создание страниц для бухгалтеров и домохозяек. Лет 15-20 назад, что там в нем сейчас, я не знаю.
Тут скорее вопрос по другому стоит - люди уже 15 лет пользуются другими редакторами, какая причина им брать dreamweaver, чем он лучше?
Vitaly Adamsov, в двух словах я вам написал во втором абзаце, подробно - у вас на картинке.
как именно реализована сама таблица на низком уровне - я думаю будет зависеть от языка, компилятора, версии, ключей компиляции и может чего еще.
включать или не включать эту логику для метода определяется языковыми конструкциями, вы пишете 'virtual' (или что там в конкретном в языке) и явно компилятору говорите - для этого метода - используй VMT.
Если подокапываться - то без меня, не согласны, расскажите как оно все на самом деле, подробно, понятно, чтобы было полезно.
Если что-то новое узнать, то непохоже.