Gary_Ihar

Подозреваю в img какой-то мусор прилетает, что и отрубает остальную часть записи. В остальном никакой разницы. Ну разве что background перезаписывает все остальные свойства(даже те что не указаны, т.е. если был задан background-color - он станет по умолчанию, т.е. прозрачным).

useEffect - это хук, который позволяет использовать сайд эффект. В классах его аналогом было использование componentDidMount, componentDidUpdate и componentWillUnmount. В нем можно делать подписки, отправлять запросы управлять анимацией и т. д.

const [data, setData] = useState(null);

useEffect(() => {
  const controller = new AbortController()
  fetchData(controller.signal).then(setData)

  return () => controller.abort()
}, [fetchData, setData])

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

const data = useMemo(() => array.map(mapper).filter(predicate).reduce(reducer), [array])

А useCallback используется, когда важна постоянность ссылок на функцию. Например, когда мы передаём ссылку в компонент, который использует React.PureComponent или React.memo, или, когда функция используется в качестве аргумента в других хуках

const handler = useCallback(() => {
  // что-то сделать 
}, [])

useEffect(() => {
  handler(value)
  // если не использовать useCallback, эффект будет срабатывать постоянно 
}, [handler, value])

Да ладно, парни. Ну хватит уже, к чему такие сложности? Берём и читаем. Вообще совсем не обязательно читать про архитектуру и абстракции именно по своему языку, хотя javascript в этом плане родился уродом.

Ок. Полиморфизм ни в коем случае нельзя рассматривать отдельно от других фундаментальных понятий - абстракция, инкапсуляция и наследование. Объект и подобные прилагаются из аксиом (хотя это-то тоже аксиомы).

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

С объектами и классами разобрались, а что же там с нашими стаканами и велосипедами. Мы уже поняли, что всё это объект, то есть грубо можно все объекты наследовать от какого-нибудь суперпредка, суперкласса, что и реализовано в некоторых языках. Но что другого общего между скейтом и стаканом, например? Конечно, можно углубляться и считать, что они все из молекул, и они все из твёрдых веществ. Однако это всё бред и СПГС, так что ответ прост - да ничего. То есть это совершенно разные объекты с совершенно разным функционалом. Более того - естесственно компьютерные модели и иерархии будут сильно отличатся от физик и химий. И это нормально, вопрос об адекватностях моделей ставиться лишь когда модель неадекватна, а до тех пор пилить можно что угодно, лишь бы работало.

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

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

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

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

Таким образом, абстракция невозможна без инкапсуляции и наследовании, как невозможен полиморфизм без, собственно, наследования. Ну а полиморфизм невозможен ещё и без инкапсуляции, которая банально бесполезна без наследования и полиморфизма. Вот такие тут треугольники с пирогами. Жаль только про пирог наврали. И про день рожденье.

Ребят, ну вы конечно интересные))

Если вы просто измените инструмент, с огромной вероятностью ничего не изменится

Что именно стремится к 0? Ответ сервера? Рендеринг компонентов? SSR ? Локализуйте проблему, проанализируйте, как можно её решать, если вдруг это действительно проблема фреймворка - посмотрите, нет ли аналогичной проблемы у других фреймворков.
У вас же под рукой целый devTools - Network, Perfomance, Memory, ... Полузуйтесь этим, ищите проблему)

Если хотите, можете скинуть ссылку, мне не лень попробовать понять, что именно у вас не так

Я думал об обратной миграции, с некста на какой-нибудь другой сср, главная проблема возникает с роутером. Его переписывание может занять много времени. При этом вероятно потребуется переработка многих компонентов проекта, потому что некстовый роутер ориентируется на файловую систему, и не умеет делать роутинг внутри компонента.
Как альтернативу могу предложить рассмотреть стандартный раектовский SSR, его можно на любом Node.js фреймворке сделать, например на экспрессе, это займет меньше времени вероятно. И еще можно попробовать After.js, он почти такой же как Next.js, но использует react-router, поэтому должно быть проще.
И использование styled-components может сильно замедлять скорость обработки страницы на сервере. Если делаете SSR, стоит либо оптимизировать код этих компонентов, либо отказаться от них в пользу аналогичных библиотек без рантайма, вроде linaria или astroturf

Если вам этот коммит не нужен - что он вообще делает в репозитории и зачем его было мержить?
Ну делаешь себе ветку и в нее cherrypick все коммиты, какие хочется (можно не делать ветку, а в условно dev ветку счерипикать все нужные коммиты)

так стоп...перечитал еще раз внимательно.
Зачем у вас файлы environment-специфичной конфигурации вообще лежат в общем репозитории с кодом? Наймите себе девопса чтоль.

приложение может разворачиваться под разной версией одного файла у каждого, чья ветка 3,4,5...

Т.е. это, по сути, конфигурационный файл и он не должен присутствовать в репозитории.

удалить этот коммит из удаленного репозитория и просто не пушить его в дальнейшем, добавив в гит-игнор

Думаю, наилучший вариант. Не следует пушить то, что потом будет мешать сливаться с основной веткой. Удалять коммит из удаленного репозитория не всегда лучший способ, предпочтительнее сделать Revert коммита с пометкой почему он убирается.

В общем, не стоит слепо следовать flux и пихать все в глобальный state (в случае redux).

Если ваше состояние разделяемо - используется несколькими компонентами и тп, то да, его стоит засунуть в state приложение, но если у вас есть форма, и она просто отправляется на сервер - то какой смысл от этих данных в сторе ?

Возьмем стандартный пример - данные пользователя (настройки, имя и тп), их имеет смысл хранить в глобальном стейте, тк они используется в множестве мест.

в общем, лично я придерживаюсь следующего:

Разделяемо ли это состояние (или мб будет разделяемым) ?
- да => храним в сторе
- нет => храним в локальном стейте

Не нужно дёргать карту напрямую. Сделайте массив с данными маркеров, заполняйте его по клику, и на его основе создавайте экземпляры компонента маркера:

import { yandexMap, ymapMarker, loadYmap } from 'vue-yandex-maps';

components: {
  yandexMap,
  ymapMarker,
},
data: () => ({
  coords: null,
  markers: [],
  settings: { /* ... */ },
}),
methods: {
  onClick(e) {
    this.markers.push({
      id: 1 + Math.max(0, ...this.markers.map(n => n.id)),
      coords: e.get('coords'),
    });
  },
},
async mounted() {
  await loadYmap({ ...this.settings, debug: true });

  ymaps.geolocation.get().then(res => {
    this.coords = res.geoObjects.position;
  });
},

<yandex-map
  v-if="coords"
  :coords="coords"
  @click="onClick"
>
  <ymap-marker
    v-for="n in markers"
    :key="n.id"
    :marker-id="n.id"
    :coords="n.coords"
  ></ymap-marker>
</yandex-map>

https://jsfiddle.net/f65hraxk/

Всё так, всё работает. Между "не работает" и "работает не так, как я задумал" есть существенная разница, попытайтесь её осознать.

Во-первых, чтобы результирующий массив был непустым, надо, как минимум, из коллбека фильтрации что-то возвращать. При использовании map'а - тоже. Кстати, а зачем map? Непонятно. Возможно, вместо него нужен some.

Во-вторых - в dataset лежат строки, сравниваете их вы с числами. Без приведения типов. Очевидно, что результаты подобных проверок всегда будут ложными.

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