BLOG
ローコード

【現場で使える Bubble #3】Reusable Element で学ぶ!共通化の心構えと実践

やほほほ!BizFreakのもふもふ担当、もふすけです!

今日は Reusable Element 機能について説明しようと思うのですが、

これについては、まず概念的な話からさせてください。とっても大事なことなので。

共通化・コンポーネント化とは

プログラミングに限らず、何かモノづくりの仕事に触れると「手順や設計をひとまとめにする」という事は、必要に迫られてよく行う事になります。

「似たようなパーツは使いまわす」という事をしないと作業量が指数関数的に増え続けて、やがてやってられなくなる。これは経験すればするほど感じていく事になるというのが実態としてあって、時間をかけてでも再利用できる形で残そうとするわけです。

こういう行いをシンプルに共通化とか呼んだりするわけですが、実質的に 道具作り のようなイメージとして抽象的に捉えて頂いた方が分かりやすいかもしれません。

そこで、今まさに実装経験を積んでいる皆さんには「似たような処理」「似たような実装」「似たような見た目」に対してよく警戒してみて欲しいです。特に、実装をまるっとコピー・ペーストした瞬間は要注意。2,3箇所に同じ内容を記述したらすぐ疑ってみるのがコツです。

というわけで、簡潔にまとめると共通化とは

共通パーツを作って、それを随所に"配置する"(もしくは"呼び出す")。

ということ。それをすると何が良いかというと

後から仕様を変えたり、見た目を調整したりしたい場合に、共通パーツの中身を修正するだけで済む。

という感じです。まずはここまで、しっかりおさえておいてください。

もくじ

  1. 共通化・コンポーネント化とは
  2. サンプルプロジェクト紹介
  3. Case 1. 同行者(複数名)の入力が必要になった場合
  4. Case 2. 仕様変更 > 「確認」ボタンを廃止
  5. Case 2-fix. RE(Reusable Element)化を判断・実施
  6. Case 3. ちょっと違う属性の人の入力が必要になった場合
  7. おわりに

サンプルプロジェクト紹介

今回は僕が怪しいお客様の役となって、かんたんな画面実装の要望を出します。

[実装要件]

  • 画面名は「✿ お名前登録フォーム ✿」にすること(厳守)
  • お名前入力フォーム。とりあえず代表者の名前がひらがなで入力できればよい
  • ひらがなかどうかはボタンを設置してチェックできるようにしてほしい
  • 「投稿」ボタンは動かなくていいので、まずは触らせてほしい

具体性が無い上によく考えたら怪しい指示ばかりですが、あくまでも「担当者目線(IT素人)で作って欲しいもの」がぽーんと飛んでくるのが第一ステップですので、案外これくらいが “現場のリアル” だったりします。

今回はこういうのに一応従っておくしかない状況を想定します。

(ちゃんとコンサルするべきという状況ですが、相手の性格次第では... まぁ、上流も色んな人付き合いが発生するものです)

真面目にやるなら 具体的な仕様を箇条書きして本当にこのまま作っていいか整理するのですが、

一旦そういう事は割愛して、とりあえず叶えました。

こんな見た目でつくりました
こちらは「確認」ボタン押下時のWorkflowとなります

…さて、とりあえずこれで納品です。

お客様「お、いいじゃんいいじゃん。でもごめん、色々伝え忘れてました。追加で要望を出します!!」

開発者一同「ですよね〜!!!」

...

Case 1. 同行者(複数名)の入力が必要になった場合

「最大5人、同行者を入力できるようにして欲しい」と言われました。旅行代理店か何かでしょうか。

とはいえ、お名前入力欄を増やせばいい話ではあるので、まずは何も考えずコピペをします。

"Group user" をCopyをして
Repeating Groupの中にペースト!!!

「確認」ボタンのワークフローまではコピーされないので、それは別途...

Workflow画面でもコピー操作
完成!

はい、所要時間3分。とりあえず動くのでこれで提出。

お客様「爆速対応ありがとうございます!!...でも、あ〜すみません自分で言っといてなんですが、確認ボタンをいちいち押すのはだるいですね、なんかこう、いい感じに出来ませんか?」

開発者一同(わかる〜!)

上流担当者「わかりました、イイ感じにしてみます!お名前を入力した直後すぐにチェックが入ればイイですね!」

...一般的には、バリデーションチェックという概念を意識する機会も無いですからね。

Case 2. 仕様変更 > 「確認」ボタンを廃止

[新規要望]

  • input部分の値が変化するたびに条件チェックを行い「ひらがな以外が入力されています」という文言を表示する
  • 「確認」ボタンは廃止

...さて、よく想像してみてもらえると分かると思うのですが、先ほどGroupを丸っとコピーして入力欄をもう1つ作ったため、

こういう要望が後から来たときに2箇所で作り直しを行う事になります

今は2箇所でいいですが、大抵2度ある事は3度以上…いや当業界では結局5箇所、10箇所、100箇所で 実装を使い回す という成り行きは多々発生します

というわけでお待ちかね、共通化判断をするなら今この瞬間がベスト!

今回はここでReusable Element作成を判断する事にします( Reusable Elementは以後 RE と略します )

つまりは この内容の修正を2箇所に施そうとする時点で共通化する理由が十分にある と考えるわけです。

Case 2-fix. RE(Reusable Element)化を判断・実施

手順としては簡単です。

すでに出来上がったものがある場合は、エレメントを右クリックすると…

"Convert to a reusable element"

なんて都合の良い変換操作があります。これを押し、適当にRE名を付けてあげればRE自体は出来上がります。

今回は input-user-name(ひらがな確認付) と命名します

変換直後は大抵何かしらのissueが出るので修正しつつ、REとして整えていきます。

RE編集画面へようこそ。

今回Issueが2つ出ているのは、AlertエレメントがRE化対象の外側にあって、RE化によって参照できなくなったからです。

入力欄1つ1つがアラートが内包していてもUIとして問題ないため(むしろ本来的?)、Alertエレメントをこの中に含めてしまいましょうか。

そのまま持ってきました。(indexページのアラートはもう使わないので削除)

この後、issue発生箇所に飛び、参照しているエレメントをペースとしたAlertエレメントに選びなおすと、issueが消えます。

さて、これでREが完成しました。

ページ編集画面に戻り、左下の要素一覧を1番下までスクロールすると、REが配置できるようになっています!

今作ったREが、エレメントとして認識されています
ドラッグして配置。元々あったGroup userは削除してヨシ。
Repeating Groupの中のグループもREに差し替え。

とりあえずは綺麗なRE化まで、完了です。お疲れ様でした!!

綺麗な仕組み化ができた所で、先ほど来ていた以下要望を 1箇所を修正するだけ で叶えてしまいましょう。

  • input部分の値が変化するたびに条件チェックを行い「ひらがな以外が入力されています」という文言を表示する
  • 「確認」ボタンは廃止

「ボタン押下時」のイベントを「inputの値が変化した時」に差し替えたいので、Replaceしてしまいます
「An input’s value is changed」イベントにReplace!
Replace後、存在しているInputエレメントを選択すれば完了

「確認」ボタンは用済みとなりましたので、削除してしまいましょう!

これで改修は完了です。

いざテスト!

ちゃんと動作している様子

Case 3. ちょっと違う属性の人の入力が必要になった場合

次の要望です。何やら別ページで 管理者名簿を登録できるようにしたい らしく、

そこではなぜか

  • お名前はすべて半角英数字、姓名の間は半角スペースでお願いします!

だそうです。

細かい事は気にせず、"こんな要望もサクッと叶えられる実装班" をやっていくとしましょう。

画面左側が今までのページ、右側が新しいページです(という事にします)

現状ではREの内部で「ひらがなだけだった場合はOK」という条件を明記しているので、そこに分岐が必要という事になります。

手段を知らないうちは「どうする?もう1つ別バージョンのREを作るか?」と考えがちなのですが、

こういう時は制約を一切取っ払って「理想的なまでに汎用的な道具を作るなら?」という事を少し考えてみるのがコツです。

冒頭で説明した通り、RE化・共通化は道具作りのようなものです。

もし、道具に

> 入力制限はどうする?  👉️「ひらがな」or「半角英数字(間に半スペ)」

という選択スイッチがあって

「REを使うために配置した後にこうしてモード切り替えができる道具だったら、1つのREに機能が纏まるのでは?」

...という考え方をして大丈夫なのです

「それくらい出来て当然」というのがコンポーネント化機能です。

最後にこういった切り替え機能を実装してこの記事は終わりとなります、もう少しお付き合いください!

この実装を行うためには RE に Property を定義してあげます

RE編集画面を開き、ElementsTreeで1番上の要素(RE自身)を選択。プロパティウィンドウを開くと「Add new property」ボタンがあります。

ここで、新しい「選択肢」Propertyを作ります。

選択肢を作るので、事前にOption Setsとして選択肢を作っておきます

OptionSet作成!

その後、「Add new property」の中で作成したOption Setsを選択、以下のように設定してAdd

既に配置しているREなのでDefault Valueまで設定。Optionalにすると空欄を許容できます!

あとはRE内でこれを参照出来るようになるので、分岐する部分を仕込みます。

詳細は割愛しますが、バリデーションチェック処理が2種類になったため、それぞれのチェック処理をCustom Eventで作成しておきます

似たようなCustom Eventを2つ作成

その上で「input’s value is changed」ではこれら2種類を”条件付きで”呼び出します

Propertyの値を参照できるので、処理分岐も作り放題
(ひらがな確認付)の限りではなくなったため、RE名から(ひらがな確認付)という表現も削除。

これにてREの加工は完了!!

REを配置しているページに戻って、REを選択してみてください。すると…

validation-rule項目が出現していて、...選べる!

以上、完成!

お客様役の僕「やば、イイ感じですね!!でもすみません、名簿管理はぜんぶ別システムでやっているっぽいんで、そっちと連携する感じでお願いできますか!」

開発者一同「始めから言えー!!(ズコーッ)」

おわりに

今回は、Bubbleの強力な機能であるReusable Elementについてほんの(氷山の一角だけ)紹介しました。コンポーネント化はいわば構造作り、設計者の世界。色々な発見、色々な工夫が多く詰め込まれた世界です(正直この記事だけでは伝え足りない!)

とりあえずBubbleの世界では、Reusable Elementを活用するだけでも、アプリケーションの開発効率が大幅に向上し、保守性も高まります。この機能を使いこなすことで、複雑な要素を簡単に再利用でき、アプリ全体の一貫性を保つことができます。

考え方としては、理想的なプログラミング作業は「手続きの記述」だけではなく全体的に「構造づくり」になっている事が必須です。これはローコードでも同じ事です。

むしろこういう重要なセンスを身に付けるのにBubbleはうってつけ!コーディング畑に入る前のトレーニングに最適だとすら思います。

以下、今となっては定型文っぽくなってしまいましたが、全力で学びたい人にとっては本当に良い職場だと思うので、宜しくお願いします。

では... コホン、

私たちのチームでは、業界最高のスピード感で新規事業開発に携わることができ、テクノロジーの力で圧倒的な成長を実感することができます。株式会社Biz Freakで一緒に成長したい方は、ぜひ以下のリンクからご応募ください。チーム一同、あなたと一緒に未来を創ることを楽しみにしています!

👉 https://bizfreak.co.jp/recruit

BACK

RECRUIT

世の中に「技術」で
価値を生み出す

JOIN OUR TEAM