共计 857 个字符,预计需要花费 3 分钟才能阅读完成。
如下图所示,为了缩小 SAP 电商云 Spartacus 客户施行时不必要的配置,Spartacus 将不少页面的路由门路的默认配置,定义在如下的 default-routing-config.ts 文件里:
批改之后,产品明细页面和 homepage 的产品超链接都一齐变更了:
这个默认配置什么时候被读取,并且如何被解析的呢?
如果仅仅依照 product 作为关键字搜寻,那么匹配后果太多了,因为这个单词太 generic 了:
而且 RoutesConfig 这个类型,多半都是被代码动静解析的。
换个思路,把 product 改成 product2,看看会不会报错:
这回难堪了,鼠标放上去,显示的 url 指向 home 链接,阐明 product 明细页面的 url 基本就没有生成,这条路也行不通。
再依据 paramsMapping 搜寻,因为咱们的代码,必定在某处,会解析这个字段:
果然,就在 semantic-path.service.ts 里:
在 semantic-path.service.ts 里增加如下打印语句:
咱们看下第一行输入,这个 / 和 login 是怎么被解析的。
在 Login.componment.html 里有个 pipe:
遇到上面这行代码:
<ng-template #login>
<a role="link" [routerLink]="{cxRoute:'login'} | cxUrl">{{'miniLogin.signInRegister' | cxTranslate}}</a>
</ng-template>
就会读取 Spartacus 里的配置,把基于语义的路由配置,转换成 url.
从 routingConfigService 里读取配置:
login 页面 url 搞清楚了,那么 product 页面呢?
奇怪,如果间接拜访如下 url:
http://localhost:4200/powerto…
页面关上后,没有看到和 product 相干的执行逻辑:
那么 Spartacus 怎么晓得要加载 product 明细页面呢?
咱们后续的文章会分享。
更多 Jerry 的原创文章,尽在:” 汪子熙 ”: