[Feature-1134][admin] Task directory supports flexible sorting

[suxinshuo]

[Feature-1134][feat] Task directory supports flexible sorting

• add task directory sorting strategy interface
• add two sorting strategies to the task directory

This closes #1134

[Zzm0809]

我认为前端使用 menu 组件即可 可以设置 children 属性,改变时 拿到 key 更新状态,触发后端接口调用(入参) 用级联组件不是特别合适

[suxinshuo]

我认为前端使用 menu 组件即可 可以设置 children 属性,改变时 拿到 key 更新状态,触发后端接口调用(入参) 用级联组件不是特别合适

不好意思，我之前没写过前端，不太清楚 menu 和 cascader 的区别，我这里是认为 menu 适用于导航链接类的，cascader 适用于分类选择类的，所以选用的 cascader。方便请教一下他们各自的适用场景，以及这里为什么 menu 比 cascader 更合适的原因吗？

[Zzm0809]

我认为前端使用 menu 组件即可 可以设置 children 属性,改变时 拿到 key 更新状态,触发后端接口调用(入参) 用级联组件不是特别合适

不好意思，我之前没写过前端，不太清楚 menu 和 cascader 的区别，我这里是认为 menu 适用于导航链接类的，cascader 适用于分类选择类的，所以选用的 cascader。方便请教一下他们各自的适用场景，以及这里为什么 menu 比 cascader 更合适的原因吗？

简单来说 menu 只需要在点击的时候拿到 key 即可 不需要做任何处理 , 在这个场景下,枚举值其实是固定的 ,不需要拼接处理,所以直接拿到key 然后更新状态 再触发接口调用, 链路更短, 而且我看你这里需要设定两个状态,但其实只需要一个状态即可

[Zzm0809]

为什么会新增一个getCatalogueSortType接口呢? 我认为直接复用之前的,加上入参即可,前端在状态中给默认就可以,一些拿不到状态的 比如 service.ts 中,入参直接默认 ,前端可以将排序类型定义为枚举, 如下(仅参考,可以结合你的思路):

export enum CatalogueTreeSortEnum {
  FIRST_LETTER_ASC = "FirstLetterSortingAscending",
  FIRST_LETTER_DESC = "FirstLetterSortingDescending",
  DIRECTORY_CREATION_TIME_ASC = "DirectoryCreationTimeSorting",
  DIRECTORY_CREATION_TIME_DESC = "DirectoryCreationTimeSorting",
  TASK_CREATION_TIME_ASC = "TaskCreationTimeSortingAscending",
  TASK_CREATION_TIME_DESC = "TaskCreationTimeSortingDescending",
}

[suxinshuo]

为什么会新增一个getCatalogueSortType接口呢? 我认为直接复用之前的,加上入参即可,前端在状态中给默认就可以,一些拿不到状态的 比如 service.ts 中,入参直接默认 ,前端可以将排序类型定义为枚举, 如下(仅参考,可以结合你的思路):

export enum CatalogueTreeSortEnum {
  FIRST_LETTER_ASC = "FirstLetterSortingAscending",
  FIRST_LETTER_DESC = "FirstLetterSortingDescending",
  DIRECTORY_CREATION_TIME_ASC = "DirectoryCreationTimeSorting",
  DIRECTORY_CREATION_TIME_DESC = "DirectoryCreationTimeSorting",
  TASK_CREATION_TIME_ASC = "TaskCreationTimeSortingAscending",
  TASK_CREATION_TIME_DESC = "TaskCreationTimeSortingDescending",
}

明白，我这里为了后续扩展其他的排序类型，做成动态的了，所以加了个 getCatalogueSortType 接口获取当前所有的排序规则用来渲染目前的排序级联列表，后续只需要改后端就可以增加排序类型和对应的排序逻辑，现在所有枚举都是维护在后端。 感觉这样做成本也不高，比前后端都维护一个枚举要好一些，所以加的这个接口

[suxinshuo]

综合上面说的，我把前端的 cascader 组件改为 menu 组件，同时修改对应的接口 getCatalogueSortType 的返回值结构。 后端新增的 getCatalogueSortType 接口(获取当前的排序类型枚举)以及目录树接口新增的入参，仍然保留，看看怎么样？ @Zzm0809

[Zzm0809]

综合上面说的，我把前端的 cascader 组件改为 menu 组件，同时修改对应的接口 getCatalogueSortType 的返回值结构。 后端新增的 getCatalogueSortType 接口(获取当前的排序类型枚举)以及目录树接口新增的入参，仍然保留，看看怎么样？ @Zzm0809

可以

[Zzm0809]

为什么会新增一个getCatalogueSortType接口呢? 我认为直接复用之前的,加上入参即可,前端在状态中给默认就可以,一些拿不到状态的 比如 service.ts 中,入参直接默认 ,前端可以将排序类型定义为枚举, 如下(仅参考,可以结合你的思路):

export enum CatalogueTreeSortEnum {
  FIRST_LETTER_ASC = "FirstLetterSortingAscending",
  FIRST_LETTER_DESC = "FirstLetterSortingDescending",
  DIRECTORY_CREATION_TIME_ASC = "DirectoryCreationTimeSorting",
  DIRECTORY_CREATION_TIME_DESC = "DirectoryCreationTimeSorting",
  TASK_CREATION_TIME_ASC = "TaskCreationTimeSortingAscending",
  TASK_CREATION_TIME_DESC = "TaskCreationTimeSortingDescending",
}

明白，我这里为了后续扩展其他的排序类型，做成动态的了，所以加了个 getCatalogueSortType 接口获取当前所有的排序规则用来渲染目前的排序级联列表，后续只需要改后端就可以增加排序类型和对应的排序逻辑，现在所有枚举都是维护在后端。 感觉这样做成本也不高，比前后端都维护一个枚举要好一些，所以加的这个接口

好的 这个确实,点赞