Как поправить regexp, чтобы url валидировался правильно?

FKV, это я знаю, но это как раз вообще не проблема. Перед тем как помещать ссылку непосредственно в href можно проверить, содержит ли она https, и если нет - то добавить. Но сначала надо проверить ссылку на валидность в целом, поскольку если она невалидна, т.е. если из нее нельзя создать рабочий тег 'a', то ничего и не будет выводиться. Т.е. схема такая, что сначала проверять, может ли строка вообще использоваться как url, а потом - добавлять к ней https, если его нет.
Можно было бы, конечно проверить/добавить https перед валидацией, а не после, но тогда практически любая чушь станет валидной.
В общем, наверное, проще не переусложнять имеющуюся регулярку, а написать отдельную, которая, в случае false в первой, будет проверять дополнительно валидность строк вида "www.google.com".

Как поправить regexp, чтобы url валидировался правильно?

FKV, не, 4 все-таки актуален, т.к. тут нужны не шашечки, а ехать, как говорится. Т.е. строго терминологически, это, может, и не урл, но если эту штуку присвоить атрибуту href, то ссылка будет рабочая. Конечная цель именно такая.

Как поправить regexp, чтобы url валидировался правильно?

FKV, именно так, по-моему было нельзя)) Ок, буду знать, спасибо.

Как поправить regexp, чтобы url валидировался правильно?

Да, но фактически ссылки с такими урлами все равно чаще всего невалидны, т.к. по ним невозможно перейти. Понятно, что какой-нибудь localhost это вполне валидная ссылка, и, вероятно, тут нет смысла так заморачиваться, чтобы пытаться отделить localhost от всего остального. Проще оставить как есть, чтобы считал такие ссылки валидными. Но вот такой вариант точно не может быть валидным - 'https://wwww.google.com/'. А такой - 'www.google.com' - точно не может быть невалидным.
То, что вы скинули мне, наверное вряд ли чем-то поможет, это же, если я правильно понимаю, штатная php-шная функция, а у меня речь идет про js.

Как поправить regexp, чтобы url валидировался правильно?

Антон Антон, потому что 4 символа "w"

Как динамически создавать экземпляры разных классов, с доступом к их типам?

Aetae, да, наверное, подсознательно, мне что-то подобное и виделось) И да, наверное, это немножко бред, согласен) Проблема просто в том, что речь идет о микрофронтенде, и в идеале мне бы хотелось избавиться от проверок на инстанс в компонентах. Потому что компоненты - это одна сущность, этот вот адаптер, о котором идет речь - совсем другая, сторонняя, по сути. Хотелось бы, чтобы первый как можно меньше знал о втором)

Как динамически создавать экземпляры разных классов, с доступом к их типам?

Alexandroppolus, ну да, я это и имею в виду - мне не нравится, что типом является Union, неважно, сколько там классов - 2 или 50, мне именно это и не нравится, что их несколько. Но наверное, от этого не уйти.
В реальности, у меня там не Animal и не Human (это просто абстрактный пример был), а два разные апи-библиотеки, и все их методы - это лишь обращения к бэку. Ну и приведение респонсов к универсальному виду. Так что, думаю, никакие важные принципы там не нарушаются.
Ну то есть условно, есть переиспользуемый компонент, который используется в разных приложениях, поэтому он не должен знать, с каким именно бэком он общается. То, куда обращаться, определяется внутри этого адаптера, который получает из компонента пропс с указанием конкретного апи и инстанцирует тот или иной класс. Но есть компоненты, которые железно будут работать только с условным Animal (и они мне известны), и есть, которые будут работать только с условным Human, т.е. я точно знаю, что в них должен отработать специфический метод того или иного класса.
В принципе, наверное, стоит просто проработать возвращаемые типы всех методов, и убедиться, что все типы совпадают, да и все.

Как динамически создавать экземпляры разных классов, с доступом к их типам?

Если ты имеешь в виду, насколько активно впоследствии эти инстансы используются - то да, весьма активно.
В принципе, большинство методов там по факту одинаковые, и с одинаковыми сигнатурами, просто я не стал заострять на них внимание, т.к. с ними никаких проблем нет. Проблема именно с уникальными и с теми, у которых разный ReturnType. Пока обхожусь в этих случаях проверкой на instanceof, если нужно вызвать специфический метод или заюзать определенный ReturnType. Главное, что меня смущает - это то, что по факту типом инстанса является Animal | Human. Хотел узнать, реально ли сделать так, чтобы работать приходилось не с Union, а с каким-то одним типом. Скорей всего, никак нереально в рантайме понять, с каким инстансом конкретного класса я имею дело, но, может, условно говоря, в таких случаях делается какой-то "объединяющий" класс, или еще что-то такое...

Как динамически создавать экземпляры разных классов, с доступом к их типам?

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

export abstract class BaseRepository {
  getEntity() {
    throw new Error("Method not implemented.")
  }
}

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

class Human extends BaseRepository {...}

Как я написал, в комменте Aetae, в реальности, почти все методы обоих классов одинаковые, и с одинаковой сигнатурой. Но проблема именно с различающимися методами и с теми, которые возвращают разные типы. Впрочем, понял, что в моей ситуации мне проще привести и их к одному типу. Но вот остается проблема именно с уникальными методами каждого класса. Непонятно, что делать с ними. И кроме того, смущает, что по факту тип моего инстанса всегда будет Animal | Human.

Как динамически создавать экземпляры разных классов, с доступом к их типам?

Ну нет, не настолько все плохо) Классов пока только два. В будущем могут появляться и новые классы, но очень редко, и это, как правило, целое событие, также что мимо меня это точно не пойдет. Т.е. сейчас я знаю, что будет либо один либо другой класс. Подавляющее большинство их методов - одни и те же, с одними и теми же сигнатурами. Просто есть и отличающиеся методы - один-два из примерно 15ти. И в паре методов отличаются ReturnType. В таких случаях, конечно, используется instanceof. Вопрос в том, как лучше реализовать вот это подобие адаптера, при инстанцировании экземпляров.

Как динамически создавать экземпляры разных классов, с доступом к их типам?

В каком смысле - весь?) Приведенных фрагментов, на мой взгляд, достаточно, чтобы понять суть задачи. Тем более, учитывая, что это утрированный абстрактный пример.

Можно ли как-то запустить Vue 2-плагин на Vue 3?

Влад Токарев, а, понял. Нет, с этим проблем как раз не было, все отлично работало)

Можно ли как-то запустить Vue 2-плагин на Vue 3?

Влад Токарев, вот это, кстати, интересный момент. Надо поизучать, как вообще себя ведет этот vue3-телепорт на микрофронтендах, я как-то не задумывался и отдельно не изучал.

Можно ли как-то запустить Vue 2-плагин на Vue 3?

Влад Токарев, так проблема не в этом, возможно, написал не очень понятно. В виджете A, который ранее был написан на vue 2, инициализировался этот плагин телепорта. А в виджетах B, C, D etc., которые по-прежнему пока на vue 2 - этот плагин использовался (напоминаю, что там архитектура на микрофронтендах). Соответственно, в виджете "A" я-то могу заюзать телепорт из ядра vue3, но все остальные виджеты, которым этот телепорт нужен, не смогут его использовать, т.к. они написаны на vue 2 и ни сном ни духом про этот телепорт.

Как типизировать подобный паттерн?

Aetae, в итоге сделал так:

type TRepoLibKey = 'api-repo-1' | 'api-repo-2';

const libRepositories = {
  'api-repo-1': ApiRepo1,
  'api-repo-2': ApiRepo2
};

const repositoryGetter = (libName: TRepoLibKey = 'lib-api') => (
  libRepositories[libName]
);

И в микроприложении получаю конкретный класс через этот repositoryGetter. Может и не слишком изящно, но работает, и позволяет не указывать каждый раз при инициализации дефолтное имя либы или класс этой либы:

const LibApi = repositoryGetter();
const b = new LibApi(apiConfig);

Как корректно сделать пересечение типов с одинаковыми именами свойств, но разными их типами?

Lynn «Кофеман», я написал не усложнение а умножение.
Вы слишком поспешно делаете громкие выводы на основе крошечного абстрактного примера, не видя реального контекста.
Абстрактные классы и пересечения типов это не то же самое. Кроме того, злоупотребление теми же абстрактными классами часто считается антипаттерном.

Как корректно сделать пересечение типов с одинаковыми именами свойств, но разными их типами?

Спасибо!

Как корректно сделать пересечение типов с одинаковыми именами свойств, но разными их типами?

Lynn «Кофеман», если бы этот общий предок был самодостаточной (т.е. использующейся независимо) сущностью - тогда да, без вопросов. В противном случае получится классическое "умножение сущностей без необходимости".

Как сделать адаптер (или вроде того) для использования нескольких api-библиотек?

Сергей delphinpro Разумеется, я знаю о существовании паттерна адаптер)
Зачем нужен адаптер под каждую либу? Так можно было бы и без адаптеров к либам обращаться. Тут скорее нужен один адаптер для всех либ. Вообще, мой вопрос это попытка выяснить, какие в целом могут быть способы решения таких задач. Можно же сделать адаптером, можно стратегией, можно билдером, можно запилить какое-то подобие BFF, можно понасовмещать разных паттернов. А может, вообще есть какая-нибудь готовая либа, и не нужно писать велосипед.

Mobx не видит массив, как это исправить?

Siiiid_z, нет, в js тоже можно.

Что касается вашего вопроса, то возможно вот это поможет, в частности, вызов makeAutoObservable c аргументами this, {}, {autobind: true}.