Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

配合 qieyun-autoderiver 0.2 #31

Closed
syimyuzya opened this issue May 5, 2022 · 3 comments
Closed

配合 qieyun-autoderiver 0.2 #31

syimyuzya opened this issue May 5, 2022 · 3 comments

Comments

@syimyuzya
Copy link
Member

syimyuzya commented May 5, 2022

@graphemecluster 已經公開了推導器 0.2 版的 PR 及相關功能的 issue,對推導方案做了新的擴展:可以動態依用戶所調整的選項值,來決定顯示或不顯示某些選項。

這個目前超出 Qieyun.推導方案.建立 的處理能力,而該 API 本來就是為了給推導器與 qieyun-examples 兩方共同使用的,因此 Qieyun.js 也需要配合它改動一下。

但實際改動之前,有些要點要先考慮一下。

推導器目前的行為

先看一下新版推導器下,推導方案的增強之處。參照原 issue 所給的演示代碼,實測並讀了下相關代碼之後,總結如下:

  • 推導方案返回的選項列表中的項,可以寫成 [選項名, 預設值(及可選值列表), 條件],增加一個第三項(boolean 型)作為該選項的出現條件。
  • 每當用戶修改選項,推導方案便會以 方案(null, null, 當前選項) 為參數重新調用一次,並顯示新的選項列表。
    • 最初一次則會以 方案(null, null, <一個特殊構造的「空」對象>) 形式調用,以獲取預設值。
  • 因不符合出現條件而被隱藏的選項,推導時不會包含在 選項 參數裡(就好像它完全不存在一樣)

我當時看到示例代碼時提出了反正都要重新調用一次推導方案,與其僅僅調整一個「可見性」,不如直接依用戶選項構造個新的選項列表返回,且這樣功能還更強,並給了代碼例。(甚至之後還想到能利用它做到更有趣的效果2333

也說是說,「選項出現條件」這個增加的部分,其實完全被另一個(無論有意還是無意引入的)更強大的功能給架空了😂

另外,除了推導器外,也會有在 Node 下用 qieyun-examples 調用推導方案的情況,它的 API 也需要考慮一下。比如這樣一例:在 qieyun-examples 下,如果我調用了 方案(地位, 字頭, { ...部分選項 }) 只給了一部分選項,按 Qieyun.js 0.13 的做法,其餘未指定的選項應當填入預設值,但由於方案可以依條件任意返回選項列表,一些選項「預設值」也可能變成動態的。所以傳入選項進行推導時,要調用兩次方案代碼,第一次獲取未指定選項的預設值,第二次實際推導。

那麼 Qieyun.推導方案 API 該怎麼辦

根據以上的分析,需要在以下方案中做一下選擇:

  1. 僅保留「出現條件」這一功能,同時不要讓推導方案能「任意」返回選項列表,而是讓它只返回一次列表,裡面的「出現條件」全都改成用 lambda(即不用普通 boolean 而是用 (當前選項: Record<string, unknown>) => boolean 作為出現條件)
  • 優點是簡單明瞭
  • 缺點是用 tuple 將來不便擴展(即使擴展了也達不到方案②的程度),且 tuple 本身意義也不那麼明朗
  1. 保留任意返回列表的功能,就不需要「出現條件」這個東西了。
  • 優點是功能強大
  • 雖然可能有意想不到的用法

個人看法是方案②比較好些。

@syimyuzya
Copy link
Member Author

syimyuzya commented May 5, 2022

@graphemecluster 推導方案新增的擴展最好整合到 Qieyun.推導方案 API 裡,這樣也是為了讓 qieyun-examples 也同步支持相同的功能。

【當然,如果需要的話(比如那個 require 功能在 Node 的 qieyun-examples 下該怎麼辦),這個 API 也可以從 qieyun-js 中分離出來,成為獨立的 package。

@graphemecluster
Copy link
Member

graphemecluster commented May 6, 2022

@syimyuzya 來回覆一些問題~

因不符合出現條件而被隱藏的選項,推導時不會包含在 選項 參數裡

這個可以包含,只要將 .pack() 改成 .pack(true) 就可以了

一些選項「預設值」也可能變成動態的

這就是 ① 的好處,雖然我現在也喜歡 ② w

所以傳入選項進行推導時,要調用兩次方案代碼

現在就是這樣

推導方案新增的擴展最好整合到 Qieyun.推導方案 API 裡

那個擴展很早期(未有 0.13 之前)就寫了,所以才暫且放在那兒而已。

按 Qieyun.js 0.13 的做法,其餘未指定的選項應當填入預設值

同上

缺點是用 tuple 將來不便擴展(即使擴展了也達不到方案②的程度),且 tuple 本身意義也不那麼明朗

其實我最初是不想用 tuple 的,可最後還是跟綾香的建議用了 tuple。


既然法師娘想到了 ②,如果大家沒異議的話(而且動態選項不成問題的話),我下個禮拜就把第三參數刪掉再移到 API 裡咯

@syimyuzya
Copy link
Member Author

該模塊已自 qieyun 分離為獨立的 https://github.com/nk2028/tshet-uinh-deriver-tools,已經實現本 issue 所述功能w

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants