AB
есть такая штука как window.location.hostname
Так он вообще никакого отношения к вопросу "отделить base URL" не имеет
Size: a a a
2020 June 08
KR
бейз урл это основа над которой вы хотите надстраивать взаимодействие с апи?
AB
бейз урл это основа над которой вы хотите надстраивать взаимодействие с апи?
А апи может быть вообще где угодно, это отдельный вопрос
KR
А апи может быть вообще где угодно, это отдельный вопрос
да но у тебя по хостнейму стоит прокся, которая это разруливает
A
давайте по порядку чтоли.
есть SPA smth с роутами /a и /b.
если оно написано с hash-based routing, оно может выглядеть, например, как stage.my.domain/smth#/a (тестовое окружение) и smth.my.domain#/a в проде. в этом случае артефакты со стейджа на прод промоутятся простым копированием, в конфиге nginx нет try_files, в в случае прихода пользователя на внутренний url приложения базовый url приложения тривиально вычисляется из window.location.pathname и window.location.hash.
если оно написано с history-based routing, начинаются последствия. в случае прихода пользователя на внутренний url приложения, stage.my.domain/smth/a, нам нужно
1 - всегда отдавать index.html на все внутренние url приложения(try_files в nginx на location /smth)
2 - на старте SPA нужно понять, а куда вообще пришел пользователь, потому что текущий url - это base url + route, и где между ними граница - хз.
в Js п.2 принято(react-router, angular) решать запеканием base url в приложение при сборке, что приводит к необходимости либо точной унификации окружений, либо правилу "все spa на поддоменах", либо невозможности промоушена копированием.
да, чисто в теории можно вычислить base url отрезая префиксы location и пытаясь выбрать роут, но это как-то довольно спорно звучит.
есть SPA smth с роутами /a и /b.
если оно написано с hash-based routing, оно может выглядеть, например, как stage.my.domain/smth#/a (тестовое окружение) и smth.my.domain#/a в проде. в этом случае артефакты со стейджа на прод промоутятся простым копированием, в конфиге nginx нет try_files, в в случае прихода пользователя на внутренний url приложения базовый url приложения тривиально вычисляется из window.location.pathname и window.location.hash.
если оно написано с history-based routing, начинаются последствия. в случае прихода пользователя на внутренний url приложения, stage.my.domain/smth/a, нам нужно
1 - всегда отдавать index.html на все внутренние url приложения(try_files в nginx на location /smth)
2 - на старте SPA нужно понять, а куда вообще пришел пользователь, потому что текущий url - это base url + route, и где между ними граница - хз.
в Js п.2 принято(react-router, angular) решать запеканием base url в приложение при сборке, что приводит к необходимости либо точной унификации окружений, либо правилу "все spa на поддоменах", либо невозможности промоушена копированием.
да, чисто в теории можно вычислить base url отрезая префиксы location и пытаясь выбрать роут, но это как-то довольно спорно звучит.
base_url формирует твое же приложение spa или ssr.
Откуда ограничение на все spa на поддоменах?
Откуда ограничение на все spa на поддоменах?
AB
base_url формирует твое же приложение spa или ssr.
Откуда ограничение на все spa на поддоменах?
Откуда ограничение на все spa на поддоменах?
Какая связь тут с ssr? Он не работает с hash-based routing, чтоли? Вроде работает, почему бы нет.
AB
base_url формирует твое же приложение spa или ssr.
Откуда ограничение на все spa на поддоменах?
Откуда ограничение на все spa на поддоменах?
"Все spa на поддоменах" - чтобы собирать их всегда с base-href=/ и ни о чём не думать.
A
"Все spa на поддоменах" - чтобы собирать их всегда с base-href=/ и ни о чём не думать.
)))
Нельзя подкинуть через env base_url?
Нельзя подкинуть через env base_url?
AB
)))
Нельзя подкинуть через env base_url?
Нельзя подкинуть через env base_url?
Ну а как env пробросить в браузер? Можно через хедеры, наверное, может получиться весело.
A
A
Достаточно
TP
Народ, я есть тут андроид разработчики кроме меня?)
Кто-нибудь думал о том, чтобы встроить repl в андроид-приложение и использовать его для дебага итд? Возможно ли это?
Кто-нибудь думал о том, чтобы встроить repl в андроид-приложение и использовать его для дебага итд? Возможно ли это?
Г
Если разберешься — отпишись. Мне инетерсно узнать
TP
Окей, я пингану если что-нибудь будет)
S
давайте по порядку чтоли.
есть SPA smth с роутами /a и /b.
если оно написано с hash-based routing, оно может выглядеть, например, как stage.my.domain/smth#/a (тестовое окружение) и smth.my.domain#/a в проде. в этом случае артефакты со стейджа на прод промоутятся простым копированием, в конфиге nginx нет try_files, в в случае прихода пользователя на внутренний url приложения базовый url приложения тривиально вычисляется из window.location.pathname и window.location.hash.
если оно написано с history-based routing, начинаются последствия. в случае прихода пользователя на внутренний url приложения, stage.my.domain/smth/a, нам нужно
1 - всегда отдавать index.html на все внутренние url приложения(try_files в nginx на location /smth)
2 - на старте SPA нужно понять, а куда вообще пришел пользователь, потому что текущий url - это base url + route, и где между ними граница - хз.
в Js п.2 принято(react-router, angular) решать запеканием base url в приложение при сборке, что приводит к необходимости либо точной унификации окружений, либо правилу "все spa на поддоменах", либо невозможности промоушена копированием.
да, чисто в теории можно вычислить base url отрезая префиксы location и пытаясь выбрать роут, но это как-то довольно спорно звучит.
есть SPA smth с роутами /a и /b.
если оно написано с hash-based routing, оно может выглядеть, например, как stage.my.domain/smth#/a (тестовое окружение) и smth.my.domain#/a в проде. в этом случае артефакты со стейджа на прод промоутятся простым копированием, в конфиге nginx нет try_files, в в случае прихода пользователя на внутренний url приложения базовый url приложения тривиально вычисляется из window.location.pathname и window.location.hash.
если оно написано с history-based routing, начинаются последствия. в случае прихода пользователя на внутренний url приложения, stage.my.domain/smth/a, нам нужно
1 - всегда отдавать index.html на все внутренние url приложения(try_files в nginx на location /smth)
2 - на старте SPA нужно понять, а куда вообще пришел пользователь, потому что текущий url - это base url + route, и где между ними граница - хз.
в Js п.2 принято(react-router, angular) решать запеканием base url в приложение при сборке, что приводит к необходимости либо точной унификации окружений, либо правилу "все spa на поддоменах", либо невозможности промоушена копированием.
да, чисто в теории можно вычислить base url отрезая префиксы location и пытаясь выбрать роут, но это как-то довольно спорно звучит.
> в Js п.2 принято(react-router, angular)
Уверены, что именно там и в сообществе, а не там, где вы с ними работали? :)
Если убрать base url вообще, что случится? Ссылки поедут? Тогда вопрос - почему, как они так сформированы, может надо как-то иначе?
Уверены, что именно там и в сообществе, а не там, где вы с ними работали? :)
Если убрать base url вообще, что случится? Ссылки поедут? Тогда вопрос - почему, как они так сформированы, может надо как-то иначе?
AB
> в Js п.2 принято(react-router, angular)
Уверены, что именно там и в сообществе, а не там, где вы с ними работали? :)
Если убрать base url вообще, что случится? Ссылки поедут? Тогда вопрос - почему, как они так сформированы, может надо как-то иначе?
Уверены, что именно там и в сообществе, а не там, где вы с ними работали? :)
Если убрать base url вообще, что случится? Ссылки поедут? Тогда вопрос - почему, как они так сформированы, может надо как-то иначе?
так это в стандартном тулинге везде.
в ангуляре точно
в ангуляре точно
ng build --base-href, в реакте вроде из CRA приплывает(но это не точно).AB
что там первым ломается по дефолту я не помню, у нас ломалась загрузка конфига из base-href/app-config.json.
ДГ
Я все понял, сори
VL
https://purelyfunctional.tv/mini-guide/clojure-web-servers/ рекомендуют ring+pedestal
Они там написали что не надо сейчас использовать http-kit - согласны с этим мнением? Jetty надежней? :)