Dynamic base href (APP_BASE_HREF) for SSR
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- angular, typescript
Hướng nghiên cứu
Bắt đầu bằng cách đọc AngularNodeAppEngine.handle và so sánh cách xử lý base-href của nó với hành vi hiện có của CommonEngine và ngExpressEngine. Theo dõi cách APP_BASE_HREF và request đi đến quá trình render SSR, sau đó xác định việc hỗ trợ base href riêng cho từng request sẽ cần những gì. Được xem là hoàn thành khi đầu ra SSR có thể sử dụng base href do request cung cấp mà không cần tự phân tích tệp index.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Which @angular/* package(s) are relevant/related to the feature request?
No response
Description
I'm using Angular as SSR multi tenant app.
We differentiate the clients per domain.
exemple:
potato.com/portal
tomato.com/citizen
onion-tickets.com
The majority from our clients use a specific base href and just a few serve the app on the root.
Right now it's difficult to work with angular with this setup, I had to do some 'stuff' on the SSR server to make it work.
We use a similar configuration for development too because it's easy to use domains rather than keep changing the client for localhost. This also allows to have many clients configured at the same time.
For the development we simply add on the OS hosts file [CLIENT].local and have nginx running on docker.
This has sped up a lot of developing time.
We are migrating from angular 16 to 19 and already preparing for the AngularNodeAppEngine because from what I saw in the docs it will be the default instead of the ngExpressEngine and CommonEngine.
At the moment there are (what I believe is regression) some things that worked in v16 that don't work in v19, and it impacts production and development.
I was preparing a repo with an example app to list those problems, but later realized that if the APP_BASE_HREF doesn't work like before, none of the other stuff matters.
This is part of the code that we use to make it work.
// this will garantee that all the js are served from the right routes.
if (condition) {
res.render(indexHtml, {
req,
document: docWithoutBaseHref
});
} else {
res.render(indexHtml, {
req,
providers: [{ provide: APP_BASE_HREF, useValue: clientBaseHref }],
document: docWithBaseHref
})
}
As you can see by the name of the variables docWithoutBaseHref and docWithBaseHref we also manually parse the index file to add and remove the base href according to the domain and base href from the request.
I look it up in the code for v19 and the base href is retrieved from the html generated on the bundling process by the .handle(req) method from AngularNodeAppEngine, this break our app because we need to put the base href that came from the SSR request, instead of reading from a static file.
Is there a possibility to have this again working with Angular?
We tested with commonEngine and it has the same capabilities from ngExpressEngine.
The problem is that I don't think the angular team will maintain multiple packages, considering that the Server routes it's supported only by AngularNodeAppEngine and it will be the future of angular SSR and the other options will be deprecated.
We would like to know if something like this will be considered to be supported by AngularNodeAppEngine?
We can still keep using the packages/code that allow our customization, but this will only delay the problem and will force us to stay attached to an older version of angular. And prevent the use of new features.
We rely on this information to make a decision about how to move forward.
Thanks.
Cheers.
Proposed solution
Allow for customization of html files from the SSR server instead of using hard coded values.
Allow to provide dynamic base href from SSR to the rendering of an angular route.
Alternatives considered
Keep using an older angular version and never upgrade.
Move to another framework.
- Ngôn ngữ chính
- TypeScript
- Star
- 27k
- Fork
- 11.8k
- Merge trung bình
- 16 giờ 35 phút
- Pull request đã merge (30 ngày)
- 176
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của angular/angular-cli
-
Can't use an array of hostnames in --allowedHosts cli parameter in @angular/build:dev-server Đang mởarea: @angular/build gemini-triaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
angular/angular-cli#33055 · 1 bình luận · 3 reaction ·
-
unit-test: with --coverage, a setup file's hooks reach only the first spec file of each worker Đang mởarea: @angular/build gemini-triaged
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 72/100
angular/angular-cli#34137 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 1 người được giao ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 1 người được giao ·
Tất cả issue của angular/angular-cli
Issue tương tự
-
[Bug]: Discord Activity titles with emoji are rejected as over 80 characters when they are not Đang mởclawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
supermomonga/zcode-acp#24 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
growthbook/growthbook#7100 ·
-
triage
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100