Power Appsでキャンバスアプリを開発中、Enum型というデータ型をたまに見かけます。
数式バーにDisplayModeとだけ書くと、式の下に次のような表示が出ます。
「列挙型」もEnumも、普段開発している中では見ないデータ型です。少なくとも、自分で定義したことはないはずです。
しかし、普段何気なく使っているDisplayModeやFormMode、ErrorKindなど、様座な場面でEnum型は登場しています。
今回は謎のデータ型「Enum型（列挙型）」について解説します。
Enum型は「名前付き定数」
Microsoft公式リファレンスのデータ型のページでは、Enum型について一瞬しか触れられていません。
列挙型 は、事前に定義された定数値を返します。 たとえば、Color は、Color.Red や Color.Blue などの事前定義された値を持つ列挙体です。
これだけだとよくわかりませんね。
ざっくり言うと「行名でアクセスできる2列のテーブル」
例えばEnum型の一つであるFormMode列挙体の中身はこうなっています。
Enumのプロパティにアクセスすると、それと対になっている定数（Value）が返ってきます。
ざっくり言えば「.(ドット)のあとに行名を書くタイプのテーブル」だと思ってもらえれば大丈夫です。
実態はPower Fxの他のデータ型
見た目はEnumという特殊な型がプロパティに使われているように見えますが、実際に値として利用されるValueは他の一般的な型です。
適当なコントロールのOnSelectプロパティに入れると、Valueを覗き見ることができます。
FormModeの場合は数値型で、
DisplayModeの場合はテキスト型です。
結局中身はテキストや数値なので、Enum型を使わずにValueをハードコードしても得られる結果は全く同じになります。
ちなみに、Enum型自体をデータテーブルやギャラリーのItemsプロパティに入れても、中身を一覧表示することはできません。「テーブル型のよう」なだけで、テーブル型ではありませんからね。
よく使うEnum型
私がよく使うEnumをいくつか紹介します。
これらのEnumのValueがどんな形なのか知っておくと、例えばSaveData・LoadDataでアプリ利用者ごとにカスタムしたUIを保存したり、フォントを事前定義されたもの以外に変更したりの応用ができるようになるので、覚えておいて損はないと思います。
Enum型のメリット
Enum型を採用するメリットとは一体何でしょうか。
プロパティに値を決まった値を入れるだけなら、テキストや数値をそのまま入力させてもいい気がしますよね？
しかし、開発者としては大きなメリットがあるのです。
1. コードの可読性の向上
フォームコントロールのDefaultModeプロパティにこう書いてあったらどうでしょうか？
2数値と意味の組み合わせを暗記していないと、何を指しているのかわかりません。
3つくらいなら覚えられそうですか？
では、StartOfWeekのように規則性がいまいち覚えづらかったり、
WeekDay(Date(2025, 4, 1), 13)Matchのように正規表現だったらどうでしょう？
IsMatch("abc123@example.com", ".+@.+\.[^.]{2,}")ぱっと見で理解するのは難しいですよね。
このような値をEnumのプロパティに包んであげることで、開発者は対照表とにらめっこしなくても値を選択できるのです。
2. コード補完の力を借りられる
ただテキスト入力するのとは違い、コード補完の力を借りることができます。
最後まで列挙型名・プロパティ名を入力しなくても、途中まで入力すれば候補か選べるようになるためコーディングが楽です。
3. タイプミス・表記揺れを防げる
テキストのフォントの太さを決めるEnum型FontWeightで標準を選択するときは、FontWeight.NormalでValueは"normal"です。太字はFontWeight.BoldでValueは"bold"です。
では、中太字であるFontWeight.SemiboldのValueはなんでしょうか？
答えは"600"です。
…は？
って感じですよね。
しかも、テキスト型の"600"。なんでやねん。
もし、テキストのベタ打ちでFontWeightプロパティを指定しなくてはならない仕様だったら、"semibold"と打ち込んで「なんで文字の太さが変わらないんだ！？」と混乱する人が続出する予感しかしません。
こういった内部実装の開発者とこちらの認識が異なることによる表記揺れを、Enumの実装によって防ぐことができます。
4. 予測外の値の混入を防ぎやすい
ErrorやMatchなどの一部を除いて、Enum型を使う場面では事前に定義された範囲のテキストや数値のみを受け付けたいですよね。
このとき、ハードコード限定だと予測外の値を入れ放題になってしまいます。
それぞれの場面で適切なEnum型を使う共通認識があれば、予測外の値を代入される可能性を低減することができます。
とはいえ、Swiftのように「指定したEnum型で代入しないとコンパイルエラーになる」という仕様ではないため、完全に予想外の値の混入を防ぐことはできません。
Enum型は開発者側で定義できない
Power Appsにおいては、2025年5月時点でEnum型を開発者側で定義することはできません。
Enumは特に複数人で開発する際にコードの意図を明確に伝えられるので、個人的には切望している機能です。
ユーザー定義関数(UDF)と組み合わせられたら、開発の際にかなり強いと思うんですが……。Microsoftさん、マジで頼んます。
データ型への理解を深めて開発を
ぶっちゃけ、今回の記事の内容は知らなくてもアプリを作ることはできます。
しかし、開発言語の特性を理解することで、エラーが発生したときの原因推測能力が上がったり、応用的な手法を思いつけるようになったりします。
ローコードだからと舐めずに、言語そのものに対しても好奇心を持って学んでいきましょう。
私もこれから頑張って理解を深めて、記事を書いていきたいと思っています。
コメント