Skip to content

Commit

Permalink
Fix submodule build issues
Browse files Browse the repository at this point in the history
  • Loading branch information
Gordon Shotwell authored Oct 20, 2023
1 parent 59ef96a commit 4c2b1b3
Show file tree
Hide file tree
Showing 4 changed files with 48 additions and 1 deletion.
1 change: 0 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,6 @@ Serve the website and watch for changes to the .qmd files:
make serve
```


Running `make` by itself will print out the available `make` targets:

```
Expand Down
1 change: 1 addition & 0 deletions api/.gitignore
Original file line number Diff line number Diff line change
@@ -1,2 +1,3 @@
*.qmd
!index.qmd
_sidebar.yml
46 changes: 46 additions & 0 deletions api/index.qmd
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# API Reference Intro

This website documents the public API of Shiny for Python. See the [Getting Started tutorial](/docs/get-started.qmd) for a more approachable introduction to the API.
The left-hand sidebar gives quick access to the full public API, and the table of contents below shows the same entries plus a brief summary for each.
Most of the reference pages include a live example app at the bottom, or at least mention another page with a relevant example.

We've intentionally designed Shiny's API so that you can `from shiny import *` to get access to most of what you need for most apps without introducing an excessive amount of namespace pollution.
Namely, it gives you:

* User interface (UI/HTML) helpers, available via the `ui` subpackage.

* To avoid clashing with this `ui` namespace when you do `from shiny import *`, you'll want to name you UI object something else, like `app_ui`.

* Reactive programming utilities, available via the `reactive` subpackage.
* Decorators for rendering `output`, available via the `render` subpackage.

* 3rd party packages that want to implement their own rendering functions are encouraged to use a `@render_foo()` naming convention so users may import with `from mypkg import render_foo`.

* A handful of other things you'll want for most apps (e.g., `App`, `Module`, etc).
* If you're using type checking, you'll also want to use the `Inputs`, `Outputs`, and `Session` Classes
to type the instances supplied to your server function, for example:


```{shinylive-python}
#| standalone: true
#| components: [editor, viewer]
#| layout: vertical
#| viewerHeight: 400
## file: app.py
from shiny import *
app_ui = ui.page_fluid(
ui.input_slider("n", "Value of n", min=1, max=10, value=5),
ui.output_text("n2")
)
def server(input: Inputs, output: Outputs, session: Session) -> None:
@output
@render.text
def n2():
return f"The value of n*2 is {input.n() * 2}"
app = App(app_ui, server)
```

{{< include _api_index.qmd >}}
1 change: 1 addition & 0 deletions py-shiny
Submodule py-shiny added at f46942

0 comments on commit 4c2b1b3

Please sign in to comment.