Skip to content
This repository has been archived by the owner on Jul 15, 2024. It is now read-only.

[package] Improve with .controlSections #35

Merged
merged 10 commits into from
Jul 15, 2024
Merged

[package] Improve with .controlSections #35

merged 10 commits into from
Jul 15, 2024

Conversation

y047aka
Copy link
Owner

@y047aka y047aka commented Feb 11, 2024

playgroundの.propsプロパティを.controlSectionsに変更し、Controlモジュールを簡素化しました。

example/src/Main.elm Outdated Show resolved Hide resolved
Copy link
Collaborator

@pxfnc pxfnc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PRに含まれている内容はよさそうです:+1:

Controlの再帰が残っているところがるので、このPR内で消せるとよさそうな気がしました!

| String (StringControl msg)
| Bool (BoolControl msg)
| Select (SelectControl msg)
| Radio (RadioControl msg)
| Counter (CounterControl msg)
| BoolAndString (BoolAndStringControl msg)
| List (List (Control msg))
| Field String (Control msg)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

こちらのControlの再帰もできれば消したいのですが、こっちは消せなさそうですかね?

Copy link
Owner Author

@y047aka y047aka Feb 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

消すためには、Control型の各Variantについて .label プロパティを追加することになると思います。
現時点では Fieldに集約して凝集度を高めておくほうが若干スマートかなというところ。
もっとも、#34 に向けてこの方法を採用したい理由があれば、このPRで予め変更しておくようにしても良いです。

別案としてplayground関数側で常に付けるような方法も考えられますが、Control.Comment にlabelを付ける可能性がほぼないので、この方法だと、別のところに冗長さが露出することになってしまう。

スクリーンショット 2024-02-12 1 14 13

Copy link
Owner Author

@y047aka y047aka Feb 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

また、将来的にテキストフィールドなどは右カラムの幅いっぱいに入力欄を広げたい可能性が大きく、そのあたりのオプションをVariantそれぞれに対してありなし決めていくよりはFieldに集約しておくほうが変更に強いかな?といったところ。

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

「コントロールセクションたちというのは、コントロールをリストにしたもの」という定義を読んだ後に、そのコントロールの定義の中に「BoolControlはコントロールでBoolと呼ぶ、SelectControlはコントロールでSelectと呼ぶ、...」と定義が並んでいる中で、「文字列とコントロールはコントロールでフィールドと呼ぶ、文字列はコントロールでコメントと呼ぶ」という定義がきているような違和感があるんですよね。

前者は純粋に何かの値を操作するための表示で、後者は「操作するための表示」文書構造を与える構造な気がしていますね〜、これをデータ型で区別したいという意図です

すごくざっくりなコードのイメージだと

-- 値を操作するための表示がどんな種類があるかの定義
type Control
  = Bool ...
  | Select
  | Radio


-- 右に表示するパネルにどんな見た目で表示できるかの定義
type alias ControlSection  
  = { sectionTitle : Maybe String
    , controls : List { label = Maybe String, control = Control }
    }
  

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

controlとcontrolの間に純粋なテキストノードを入れるのであれば、type Node = TextNode String | Control (Maybe String) ControlのようにしてsectionBody : List Node にしてしまうのも良いかなという感じです。

改めてまとめると、現在のControlは「値をどうコントロールするかの表示」と「サイドパネルにどのような文書構造を持たせるか」が混ざってしまっているので、List (List (Control msg))をなくすのであればそこまでやりきりたいです!

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

932d29a e4b2404
ControlField型を経由して、最終的にNode型を導入しました。

@@ -2,8 +2,7 @@ module Emaki.Control exposing
( Control
, StringControl, BoolControl, SelectControl, RadioControl, CounterControl, BoolAndStringControl
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

この辺はリネーム前の xxxProps が適切だったかもしれない。
このPRでは気にしないでおきます。

@y047aka y047aka merged commit bd51f95 into main Jul 15, 2024
1 check passed
@y047aka y047aka deleted the propsSections branch July 15, 2024 11:14
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants