[Feature Request] 针对非一级目录路径提示的设计方案

[lblblong]

[Feature Request] 针对非一级目录路径提示的设计方案

[lblblong]

感谢提供思路！

但是不去支持非一级目录页面的主要原因是：不太好判断一个文件是页面还是组件，比如下面这种结构

这种情况肯定需要用户在目录下放某种文件来标识才可以，但是这样就变得麻烦了
我也考虑过通过 app.config.ts 里的 pages 来确定哪些是页面，但其实我们开发过程中经常会注释掉 pages 中的一些页面，不管是出于加速构建还是什么目的，所以在开发过程中 pages 是不可信的

所以就放弃非一级目录页面的支持了

[MatrixAge]

可以参考Umi的文件路由识别规则，这一套东西在Egg和Umi都已经有了比较成熟的识别方案，可以直接拿来用的

[lblblong]

大概看了一下 umi 的约定式路由，他识别页面的规则是这样的：

这个不符合写小程序的直觉，因为这会导致开发者在页面下放组件必须要以 components 为文件夹名，如果他没有看文档，就会很懵：为什么我页面下一个 avatar 组件会被识别成路由方法 Router.pages.user.toAvatar()

egg 的识别相对比较简单，他们把对应目录的文件直接生成绑定到 requestContext 就行了，好像没有可以搬到 Taro 上的

[MatrixAge]

其实你说的“反直觉”，叫做“约定大于配置”，什么意思，pages这个对象它有，意味着很方便，也意味着有一定的学习成本。

可能你理解错了我的意思，我说的意思是pages对象单独使用：

import {pages} from 't-r-n'

Router.navigate({ url : pages.user. setting })

这样就不会出现反直觉的链式调用那。

对于React项目，Umi的规则其实已经描述的很清楚了，也算是一种业界常识，你拿到文件树，按照上述规则，遍历一下pages对象就出来了。

我相信只要是用React写过大型项目的人，会知道这种规范的必要性，以及对于后期维护的便利性（意味着你不会被其他人的各种奇葩命名搞晕）

如果你用过一些后端MVC框架，譬如Laravel、Nestjs，你会发现它们都会对命名和文件路径进行规范，这对于多人协同开发大型项目，还是很有用的。

[lblblong]

你说的导出一个包装了路径字符串的 pages 对象给开发者，这个确实是有一定的需求的，但是这意味着他已经引入了 tarojs-router-next-plugin 这个包了，我会更希望他用生成的 Router.to 方法，而不是用 Router.navigate 方法，这也就不需要 pages 对象了

约定大于配置其实在我这个库里也是有的：

Umi 的约定式路由规范并不算是业界常识，我就不是很清楚，比他更流行的 next.js 相对来说就更自由一些，只要是 pages 目录的 jsx 文件或目录都会生成对应的路由

我没在 nest 里看到太多命名和文件路径的规范，在我使用的过程中只要给上装饰器，并且在 module 注册就可用了，存在哪，用什么名字完全是我定义；约定大于配置更多还是体现在 egg 上，service、controller、config 等等各种都要放在约定的目录里，这一定程度上也限制了 egg 的发展，所以阿里又打着无服务器推出了 midway ，这个更像 nest

其实我这个只是一个库而已，约定太多会很难用，众口难调，如果我是一个很流行框架，才有机会反过来约束开发者，去做一些约定大于配置的事情

[MatrixAge]

pages对象是optional的，也不是功能强制性用法，所以应该不会对其他开发者造成困扰

[MatrixAge]

想了一下，我还是自己写一个包来实现吧，这个需求其实可以从你这里剥离出去，做成一个小程序通用方案

[lblblong]

想了一下，我还是自己写一个包来实现吧，这个需求其实可以从你这里剥离出去，做成一个小程序通用方案

是的，这个其实在 taro 的物料市场是有的，比如这个就是：
https://github.com/xdoer/generated-plugin-taro-router-service

方便路由跳转是最基础的一面，我这个库更多是路由中间件和同步路由方法，这些其实才是我开发过程中感觉到的真正的痛点，也是这个库的初衷

[MatrixAge]

想了一下，我还是自己写一个包来实现吧，这个需求其实可以从你这里剥离出去，做成一个小程序通用方案

是的，这个其实在 taro 的物料市场是有的，比如这个就是：
https://github.com/xdoer/generated-plugin-taro-router-service

方便路由跳转是最基础的一面，我这个库更多是路由中间件和同步路由方法，这些其实才是我开发过程中感觉到的真正的痛点，也是这个库的初衷

看了一下这个库，设计得不是到位，特别是和t-r-n功能部分重叠了，还一大堆前置条件，差不多和直接用node脚本执行差不多了，没啥使用价值，还是自己来吧，至少pages设计出来是跨平台的，zero config的，只要是小程序都可以用的

[lblblong]

可以的，再次感谢提供想法！