Merge pull request #23 from atorus-research/make_pkgdown

Start setting up pkgdown

.Rbuildignore

@@ -4,3 +4,7 @@
 ^README\.Rmd$
 ^cran-comments\.md$
 ^inst/parentApp
+^_pkgdown\.yml$
+^docs$
+^pkgdown$
+^\.github$

.github/.gitignore

@@ -0,0 +1 @@
+*.html

.github/workflows/pkgdown.yaml

@@ -0,0 +1,50 @@
+# Workflow derived from https://github.com/r-lib/actions/tree/v2/examples
+# Need help debugging build failures? Start at https://github.com/r-lib/actions#where-to-find-help
+on:
+  push:
+    branches: [main, master]
+  pull_request:
+    branches: [main, master]
+  release:
+    types: [published]
+  workflow_dispatch:
+
+name: pkgdown
+
+permissions: read-all
+
+jobs:
+  pkgdown:
+    runs-on: ubuntu-latest
+    # Only restrict concurrency for non-PR jobs
+    concurrency:
+      group: pkgdown-${{ github.event_name != 'pull_request' || github.run_id }}
+    env:
+      GITHUB_PAT: ${{ secrets.GITHUB_TOKEN }}
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: r-lib/actions/setup-pandoc@v2
+
+      - uses: r-lib/actions/setup-r@v2
+        with:
+          use-public-rspm: true
+
+      - uses: r-lib/actions/setup-r-dependencies@v2
+        with:
+          extra-packages: any::pkgdown, local::.
+          needs: website
+
+      - name: Build site
+        run: pkgdown::build_site_github_pages(new_process = FALSE, install = FALSE)
+        shell: Rscript {0}
+
+      - name: Deploy to GitHub pages 🚀
+        if: github.event_name != 'pull_request'
+        uses: JamesIves/github-pages-deploy-action@v4.5.0
+        with:
+          clean: false
+          branch: gh-pages
+          folder: docs

.gitignore

@@ -2,3 +2,4 @@
 .Rhistory
 .RData
 .Ruserdata
+docs

DESCRIPTION

@@ -1,11 +1,36 @@
 Package: matte
-Title: What the Package Does (One Line, Title Case)
+Title: Opinionated Backend and Reusability Focused Considerations for Shiny
 Version: 0.0.0.9000
+Description: Purposefully simple helper functions, tools, and a framework for creating reusable applications fit for production in clinical systems.
 Authors@R: 
-    person("First", "Last", , "first.last@example.com", role = c("aut", "cre"),
-           comment = c(ORCID = "YOUR-ORCID-ID"))
-Description: What the package does (one paragraph).
+    c(
+    person(given = "Maya",
+           family = "Gans",
+           email = "maya.gans@atorusresearch.com",
+           role = c("aut", "cre")),
+    person(given = "Laura",
+           family = "Maxwell",
+           email = "laura.maxwell@atorusresearch.com",
+           role = "aut"),
+    person(given = "Jiwan",
+           family = "Heo",
+           email = "jiwan.heo@atorusresearch.com",
+           role = "aut"),
+    person(given = "Atorus Research LLC",
+           role = "cph"),
+    person(given = "Mike",
+           family = "Stackhouse",
+           role = c("ctb"),
+           email = "mike.stackhouse@atorusresearch.com",
+           comment = c(ORCID = "0000-0001-6030-723X"))
+    )
 License: MIT + file LICENSE
+Depends: R (>= 3.5.0)
+Imports:
+    renv,
+    golem,
+    rhino,
+    usethis
 Suggests: 
     testthat (>= 3.0.0)
 Config/testthat/edition: 3

README.md

@@ -0,0 +1,73 @@
+
+<!-- README.md is generated from README.Rmd. Please edit that file -->
+
+# { matte } - an Enterprise Shiny Manifesto
+
+And the not so glamorous back-end considerations for Shiny
+
+## The Parent-Child App Relationship
+
+A common paradigm we’ve come across is the desire to create a Shiny app
+but have it used across different datasets with different scoped access
+to those datasets. It’s also common for the data to need some
+transformation prior to being used in the application. For these reasons
+we propose an opinionated paradigm of creating a package of Shiny
+modules, then using that package in child repositories, each with their
+own data.
+
+Creating child repositories for each application instance solves the
+problem of changing and editing code in a single place, then persisting
+those changes to multiple endpoints, while still allowing for
+customization at the child application level. This is important in
+industries such as pharma because we can go through validation cycles
+and use certain versions of the parent package for some clinical
+studies, and experimental versions for others. It also allows for bug
+fixes in a central location, rather than forking a Shiny app and needing
+to make changes in multiple places.
+
+## A Consistent Data Structure
+
+The child repository has an `app.R` file at the root level, and ui and
+server function that call modules from the parent. This doesn’t limit
+child applications to the parent structure, but the modules from the
+parent should assume as certain data structure to be used within the
+child applications. We propose creating a single object and storing it
+as `data.rds`. In the `{matte}` paradigm we create a `jobs` folder with
+a `data_prep.Rmd` - this takes the raw data needed for the application
+and manipulates it to be the generic structure needed for all apps. But
+what if your data is different between child repositories, you ask? We
+also include a `meta.yaml` file, a list of key value pairs for mapping
+columns to the application.
+
+## An Example
+
+This can all seem very abstract, in `inst/examples` we’ve included an
+example of this paradigm:
+
+`parentpkg` is a package with `mod-chart` and `mod-table` `child1` is a
+shiny application that uses `parentpkg`’s modules as well as themeing
+with a data preperation file from `mtcars` `child2` is a shiny
+application that uses `iris`
+
+`child1` and `child2` look and feel like they come from the same
+ecosystem with the same branding, but this structure allows for further
+customization like including a third module custom to `child2` that may
+not be in `child1`.
+
+## Can I use this with other Shiny frameworks?
+
+Because the `jobs` endpoint is secondary to the application itself, you
+can use the `{matte}` paradigm with children applications that are
+Rhino, Golem, or native Shiny! The only limitation is that the parent
+application must be a package so that you can call it within the
+children.
+
+## Installation and Use
+
+You can install the development version of matte from
+[GitHub](https://github.com/) with:
+
+``` r
+# install.packages("devtools")
+devtools::install_github("atorus-research/matte")
+```

_pkgdown.yml

@@ -0,0 +1,4 @@
+url: ~
+template:
+  bootstrap: 5
+