LINUX.ORG.RU

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

 , ,


0

0

Я дошёл до этапа, когда у меня есть название контроллера и метода в переменной. Мне нужно используя эти переменные вызвать нужный метод

Контроллеры и методы представлены в следующем виде:

// базровый класс для всех контроллеров
class Controller {}

class Global extends Controller {

    // метод
    doStart(): object {
        return {
            status: 'ok',
            message: 'я работаю, всё ок',
        };
    }
}

Теперь нужно имея переменные controller: string и method: string вызвать нужный мне метод. Я затрудняюсь как. Кто знает — подскажите, пожалуйста :)

[hr]

Я пробовал сохранять методы в key-value массиве, чтобы метод можно было получить по строке. Вот так:

class Global extends Controller {
    _allow_method_list = {
        doStart: this.doStart,
    };
}

Этот это не подходит, потому что в этих методах почему-то нельзя использовать this, а это существенно и вообще знак что я что-то делаю не так.



Последнее исправление: elonmusk (всего исправлений: 1)

Ответ на: комментарий от anonymous

Выбор жс обусловлен прежде всего унификацией,

чуш какая то. JS обусловлен тем что как бы нет другого языка на платформе (компиляторы из котлинов, дартов и прочего не в счёт т.к. не мейнстрим(а это важно ибо с тем же успехом можно и лиспах писать и бед не знать)).

А если я не хочу жрать дерьмо, то спокойно беру условный rpc + protobuf + ws и мне как-то похрен на всё.

а рендерить ты это всё как будешь? мы как бы разговор про SPA ведём иначе то JS как таковой роли не играет и зачастую даже не нужен. А если про бекенд то там вообще «фреймворк» пишется за 3 часа, только зачем это делать не понятно если есть условный express и братия на любой вкус.

Для чатика ненужная никакая асинхронность

давай не будем заливать, то что можно и без неё не значит что это лучшее решение.

Всё зависит от условий.

условия веба таковы что рендерить страницу на JS (а для другого и не нужны свои и чужие фреймворки) мега сложно, вся эта сложно в управлении состоянием (именно про это все фреймворки).

Noob_Linux ★★★★
()
Ответ на: комментарий от Noob_Linux

чуш какая то. JS обусловлен тем что как бы нет другого языка на платформе (компиляторы из котлинов, дартов и прочего не в счёт т.к. не мейнстрим(а это важно ибо с тем же успехом можно и лиспах писать и бед не знать)).

Ты там не про фронтенд говорил, а про другое. Или ты уже сам не помнишь о чём говорил? Давая я тебе напомню - на что именно я отвечал:

Для бекенда брать js не стоит

Вот тебе и объяснили - зачем для бекенда брать жс. А ты всё перепутал.

По поводу съезжания на «менстрим» - ты уж там определись, мы говорим об 1/10, либо о 9/10. Но я тебе напомню - мы говорим об 1/10 и на мейнстрим нам как-то насрать. Наш случай исходит из того, что мы можем себе позволить «чуть» больше, нежели мейнтрим и ссылаться на мейнтрим тут некорректно.

а рендерить ты это всё как будешь?

А с чего ты решил, что реакт что-то там рендерит? «Рендеринг»(если мы назовём это рендерингом) там примитивный, а вся суть в эмуляции пхп. Для рендеринга эмуляция пхп не нужна.

А если про бекенд то там вообще «фреймворк» пишется за 3 часа,

Ну вообще-то ты сам говорил в том числе и бекенде, да и автор о нём говорил.

только зачем это делать не понятно если есть условный express и братия на любой вкус.

Наверное в том, что всё это говно убогое. От этого уже даже мейнстрим бежит куда подальше.

давай не будем заливать, то что можно и без неё не значит что это лучшее решение.

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

Но даже если мы уйдём от асинхронности - ты всё равно всё перепутал. На пхп чатик не делается не потому, что он какой-то там «не асинхронный», а на ноде он делается не потому, что она какая-то там асинхронная. Там просто разные модели исполнения и асинхронность к этому отношения не имеет.

условия веба таковы что рендерить страницу на JS

Самая примитивная задача.

(а для другого и не нужны свои и чужие фреймворки) мега сложно

Да нет же, реакт очень примитивен, даже если брать его как эмулятор пхп, а не как рендер.

вся эта сложно в управлении состоянием (именно про это все фреймворки).

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

Это такой типичный нюанс. Зачастую «как делать» важнее «что делать».

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

Ты приписываешь сложность решения левой проблемы к сложности рендеринга, но это неверно.

anonymous
()
Ответ на: комментарий от Noob_Linux

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

Во-вторых, подобные «частные» случаи не являются «частными», а являются достаточно частыми случая в мейнстриме, особенно в мейнстриме. Там вообще шаринг кода между фронтом/беком - один из столпов существования ноды.

anonymous
()
Ответ на: комментарий от anonymous

Вот тебе и объяснили - зачем для бекенда брать жс. А ты всё перепутал.

не объяснил, поэтому я думал что бы говорим о фронте.

Но я тебе напомню - мы говорим об 1/10

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

А с чего ты решил, что реакт что-то там рендерит?

если уж докапываться то да сам react innerHtml не вызывает (это делает react-dom) но это самая не важная задача рендеринга. Из всего что ты сказал могу лишь констатировать что ты по верхам пробежался («эмулировать PHP» очень яркая аналогия которая говрит о глубине понимания) и толком не в давался зачем и для чего вся эта штука нужна, а уж тем более как она работает.

Ты приписываешь сложность решения левой проблемы к сложности рендеринга, но это неверно.

Js фреймворк это фронт (99 из 100 случаев т.к. на ненужность бекенда на JS я уже указал ранее, но и не имею ничего против него), фронт это рендер, рендер это сложно

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

Noob_Linux ★★★★
()
Ответ на: комментарий от Noob_Linux

не объяснил, поэтому я думал что бы говорим о фронте.

Основание?

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

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

если уж докапываться то да сам react innerHtml не вызывает (это делает react-dom) но это самая не важная задача рендеринга. Из всего что ты сказал могу лишь констатировать что ты по верхам пробежался («эмулировать PHP» очень яркая аналогия которая говрит о глубине понимания) и толком не в давался зачем и для чего вся эта штука нужна, а уж тем более как она работает.

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

Js фреймворк это фронт (99 из 100 случаев т.к. на ненужность бекенда на JS я уже указал ранее

Тебе уже ответили на это, но ты пхп-трепло продолжаешь оправдывать своё нелепое существование, игнорируя тезисы оппонента.

но и не имею ничего против него), фронт это рендер, рендер это сложно

Для тебя, птушника да, но что там для тебя сложно, как и твои представления - меня не волнуют.

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

О да, очередной клоун обосрался и убежал. Беги, убогий.

anonymous
()
Ответ на: комментарий от anonymous

а вся суть в эмуляции пхп

Все-таки пхп это текстовый шаблонизатор. React наследник идеи hyperscript и эта история вовсе не про «эмуляцию PHP»

Deleted
()
Ответ на: комментарий от Deleted

Все-таки пхп это текстовый шаблонизатор.

Неверно, абсолютно неважно кто и какой шаблонизатор - дело не в этом, дело в том, что реакт такой же шаблонизатор.

Дело в том, что пхп - это такая херня, исполнение кода которого поражало страницу. Данные на вход, страница на выход. Этот тот самый «однонаправленный поток данных», там даже потока нет - это всё прикручено сверху. Там просто данные.

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

https://github.com/hyperhype/hyperscript

Это говно никакого отношения к теме не имеет. Это просто про написания хтмл синтаксисом/объектной моделью жс. Реакт не занимается этим - это лоулевел, который не имеет никакого отношения к тому, как выглядит реакт сверху.

Всё это нужно потому, что жс(в отличии от пхп) не умеет в хтмл. Как только жс в этой научился - появилось развитие идеи далее - ты можешь это посмотреть новых версиях жсх"а на строках, style-components с их css-аля пхп и прочее.

«hyperscript» - это просто костыль, использование которого было обусловлено отсутствием в жс нужных возможностей.

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

Это фундаментальная разница между dom/любой объектной моделью и php. Объектная модель живая, она существует на уровня языка и с ней можно взаимодействовать. Реакт это не про это. Он просто рядовой шаблон.

anonymous
()
Ответ на: комментарий от Deleted

К тому же, ты можешь дойди до этого не через матчасть, а просто через фейсбук. Кто основной пользователь пхп, кто занимался его развитием и кто сделал реакт? Совпадение? Не думаю.

anonymous
()
Ответ на: комментарий от anonymous

Не смог вычленить из этого потока сознания аргументы, опровергающие довод о том, что текстовый шаблонизатор !== дерево элементов на структурах языка

Deleted
()
Ответ на: комментарий от Deleted

В очередной раз макака обосралась. Беги отсюда, дошколятина позорная.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.