これは、 以前の出版物の続きです。
当然、名前は面白いですが、よく知られているように、すべてのジョークにはいくつかの真実があります。 このトピック自体は、次の100回目に、「柔軟なレポート/グラフデザイナー」が必要であるというしつこい願いを聞かなければならなかったときに生まれました。 一定のポイントをtidyverseと、 tidyverseが必要なすべてのニーズをカバーしていることをもう一度説明するよりも、実行する方が簡単です。
問題のステートメント自体は非常に簡単です。任意の表形式データを使用してさまざまなグラフィカル表現を描画するためのグラフィカルインターフェイスを提供します。 従来のソリューションは、2つの関連するエンティティです。
- 多数のメニューとボタン、およびこれらの要素の相互状態を制御する複数の舞台裏
IFを備えたインターフェイス。 - フィードデータとUIで設定されたスライダーの位置に応じてグラフをレンダリングするための多数の組み込み
IFを備えた「柔軟なプロッター」。
一方で、「まだ別のタブロー」を作成することはまったく面白くない。 一方、「すべてを実現するが何もする必要がない」というスタイルでのステージングは、TRIZの典型的なタスクです。
一般に、ある程度の検討の後、最新の定式化をほぼ満たすソリューションが開発されました。 Shinyアプリケーション自体はまだNDAの下にあり、自由に公開されたプロトタイプが写真に示されています。
タスクを簡素化するための2つの重要なアイデアは次のとおりです（新しいものは何もありません。すべてが私たちの前に発明されています）。
- 静的に指定されたUIの代わりに、動的に生成されたUIに渡します。
- Rインタープリターは、ソースコードだけでなく、コード自体の内部でも使用します。
アイデア1.動的なWebベースのインターフェース
すべての制御要素が静的に設定され、パラメーター化の変更（名前、状態、リスト、選択された要素など）のみがオプションである場合は、設計段階で便利です。 すべてが明確で、すべてが明白であり、ペンに触れることができます。 しかし、これらの要素の許容状態が、分析の初期データ（ data.frame ）と互いの状態の両方に非常に強く関連している場合、各要素の非常に多数の非自明なイベントハンドラーの状況にいることにdata.frameます。 たくさんの紛らわしいコード。
別にやってみましょう。 複雑な動作をするUI要素の代わりに、 uiOutputを使用してプレースホルダーをuiOutputさせ、 shiny::renderUIを使用してこの要素の表現を動的に計算および生成します。 要素の生成に必要なすべての外部パラメーターは、リアクティブ要素として扱われます。 さらに、このようなインタラクティブな要素はすべて、環境を見てそれに適応する「自律エージェント」として機能します。 ユーザーは1つの要素の状態を変更しました-すべての常習者は順番に状態を再計算し始めました（明らかにイベントを処理しませんが、光沢のあるリアクティブアプローチを使用します）。 それらの状態が変化すると、新たに誘発された変化が起こる可能性があります。 そして、すべてが安定するまで。
その結果、コードにはハンドラーが1つだけ残ります（「実行」ボタン） observeEvent(input$gen_plot, { # escname <- function(x){ # # ..... } point_code <- "" if(input$shape_type!="__NO_MAPPING__") { aes <- c("shape"=escname(input$aes_shape_col), "color"=escname(input$aes_color_col)) point_code <- buildPointCode(fixed=c("shape"=input$shape_type, "color"=glue("'{input$plot_color}'")), aes=aes) } line_code <- "" if(input$line_type!="__NO_MAPPING__") { aes <- c("linetype"=escname(input$aes_linetype_col), "color"=escname(input$aes_color_col)) line_code <- buildLineCode(fixed=c("linetype"=input$line_type, "color"=glue("'{input$plot_color}'")), aes=aes) } gcode <- glue("ggplot(data_df(), aes(x=`{input$x_axis_value}`, y=`{input$y_axis_value}`))\\ {point_code} {line_code} + xlab('{input$x_axis_label}')") %>% style_text(scope="spaces") plot_Rcode(gcode) })
要素の依存関係は非常に難しく、多段階になりますが、平衡状態は高速であり、これはすべてユーザーには見えません。 アナリストと開発者にとって、これはボンネットの下に隠されています。 生活を簡素化するために、エンドユーザーにggplot表示される数字の代わりにポイントとラインの写真をggplotます。
アイデア2.通訳Rの再利用
多くの人々は、Rが「彼は通訳だから遅い」という事実を突くのが好きです。 そのような声明の根拠のない根拠のないこと（詳細に説明したい人はいません）を除外して、この「弱さ」を力として使用します。
パラメーター化された（非標準評価にようこそ！）ソースデータを生成し、グラフィックスを生成するときにUIの状態のすべてのニュアンスを考慮する複雑な「柔軟なプロッター」を作成する代わりに、整然とした方言Rコードジェネレーター（文字列など）を作成します。その後のソフトウェア実行（評価）で、必要なスケジュールが生成されます。
output$staticPlot <- renderPlot({ base::eval(parse(text=req(plot_Rcode))) })
ひれ
光沢のあるプロトタイプ「アラタブロー」は、UIパーツ、コメント、複数の検証（アサーション）を含む250行のコードに収まり、ライセンスで0ルーブル0コペックします。
ハッピー2018年！
前の出版物- 「Rおよび情報セキュリティ。 利益相反を解消し、LinuxでRをオフラインで実行する方法 。