-
Notifications
You must be signed in to change notification settings - Fork 154
Components #522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Components #522
Conversation
* update button.md * update markdown text section
* first draft inputs overview * updates nav with javascript/inputs * Apply suggestions from Fil review Co-authored-by: Philippe Rivière <[email protected]> * updates to use olympians, uses lowercase and 'inputs' throughout * case fixes and minor update Co-authored-by: Philippe Rivière <[email protected]> --------- Co-authored-by: Allison Horst <[email protected]> Co-authored-by: Philippe Rivière <[email protected]>
|
* change todos to comments and add Inputs.search doc * add API reference
Co-authored-by: Allison Horst <[email protected]>
docs/javascript/inputs.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should start with a generic description of what “inputs” are within the concept of the Observable CLI before introducing “Observable Inputs” as a specific solution. It should mention the concepts (and link to) the concepts of reactive top-level variables, generators, and the display function, and then first introduce the view
function as how inputs are declared. We should also mention that Generators.input
is used under the hood, and link to that too (see Observable Generators).
Only after these concepts are introduced should be introduce Observable Inputs as a library (an implementation) of commonly-needed input components, each of which is a function that returns an HTML element that emits input events (for compatibility with view
and Generators.input
).
So, yes, the first code snippet of actual usage should be view
+ Inputs.whatever
, so that people see what the recommended usage pattern is. But the text needs to explain what’s happening so that people have a conceptual understanding of how it works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updates here: #545 (merged into Components branch, top-level Inputs page)
docs/inputs/us-state-capitals.tsv
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is already available in docs/lib and we shouldn’t duplicate it. We could move (static) data files to docs/data, but that’ll mean a few more relative paths in the examples. Maybe that’s fine… and it would be consistent with what we now recommend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could move (static) data files to docs/data, but that’ll mean a few more relative paths in the examples. Maybe that’s fine… and it would be consistent with what we now recommend.
I think we should do this.
docs/charts/histogram.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To align with Plot’s mental model, perhaps better to combine this and the hexbin example into a bin.md that demonstrates group, bin, and hexbin transforms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this.
I am stuck on naming. The existing sidebar items and page titles are general chart types (e.g. "Line", "Area" for nav, "Line charts", "Area charts" for page title).
Here, that could be something like:
- Sidebar: "Aggregation", "Summary"
- Page title: "Summary charts", "Aggregated data", "Aggregated charts", "Charts with aggregated/binned/grouped data" (?)
Recommendations for naming this section (in the sidebar, and page title) are appreciated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my suggestion: "Grouping data"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will add "Grouping data" page with histogram, hexbin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in #560
* update inputs-overview intro text * links * remove h2 for intro * adds Inputs general intro, update view documentation in Display page * Update view summary in javascript/display Co-authored-by: Philippe Rivière <[email protected]> * Apply suggestions from code review Co-authored-by: Philippe Rivière <[email protected]> --------- Co-authored-by: Allison Horst <[email protected]> Co-authored-by: Philippe Rivière <[email protected]>
Adds `card` class --------- Co-authored-by: Allison Horst <[email protected]> Co-authored-by: Robert Harris <[email protected]> Co-authored-by: Cindy <[email protected]> Co-authored-by: Philippe Rivière <[email protected]>
observablehq.config.ts
Outdated
@@ -15,10 +16,58 @@ export default { | |||
{name: "Imports", path: "/javascript/imports"}, | |||
{name: "Files", path: "/javascript/files"}, | |||
{name: "Promises", path: "/javascript/promises"}, | |||
{name: "Inputs", path: "/javascript/inputs"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let’s move this to after Display. (I don’t want to interrupt Promises and Generators, which are closely related in terms of implicit resolution of values across code blocks, and Inputs are closely related to Display.)
Adds brief overview of components (layout, charts, inputs) --------- Co-authored-by: Allison Horst <[email protected]> Co-authored-by: Philippe Rivière <[email protected]>
* add Grouping data section with hexbin, histogram * adds Grouping data page to sidebar in Charts * minor fixes and update hexbin chart to use dot mark * Apply suggestions from code review Co-authored-by: Philippe Rivière <[email protected]> --------- Co-authored-by: Allison Horst <[email protected]> Co-authored-by: Philippe Rivière <[email protected]>
* add grid doc * change how example code is rendered * remove word salid * improve advice * fix capitolization * Update docs/layout/grid.md Co-authored-by: Philippe Rivière <[email protected]> * Update docs/layout/grid.md Co-authored-by: Philippe Rivière <[email protected]> * Update docs/layout/grid.md Co-authored-by: Philippe Rivière <[email protected]> * Update docs/layout/grid.md Co-authored-by: Philippe Rivière <[email protected]> * remove overshare --------- Co-authored-by: Philippe Rivière <[email protected]>
* add resize doc * fix some typos * fix formatting * add both cases
Things I noticed during quick overall review, but did not update:
|
docs/components.md
Outdated
Observable Markdown offers a number of [built-in themes](./config#theme) that you can compose to create, say, wide pages with an alternative dark color theme: | ||
|
||
```js run=false | ||
theme: ["dark-alt", "wide"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is dark-alt
an official theme? or should it be ["dark", "alt", "wide"]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating to ["dark", "alt", "wide"] thanks!
docs/components.md
Outdated
|
||
```yaml | ||
--- | ||
theme: ["dark-alt", "wide"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think both [dark-alt, wide]
(without quotes) and ["dark-alt", "wide"]
works. could we standardize between https://cli.observablehq.com/config#theme and here? also I see the pattern of having the description and then the code block:
The code below, when included in the [config file](./config), specifies the default theme for the project:
```js run=false
theme: ["dark-alt", "wide"]
```
In addition, you can specify the theme for a single page in its [front matter](markdown#front-matter):
```yaml
---
theme: ["dark-alt", "wide"]
---
```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating to match pattern in config (quotes in config file, no quotes in frontmatter)
Resize exists in the Observable standard library, or can be imported explicitly: | ||
|
||
```js | ||
import {resize} from "npm:@observablehq/stdlib"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: should we add this to show the explicit import?
import {resize} from "npm:@observablehq/stdlib";
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, added echo
const pickSpecies = view(Inputs.radio(["Adelie", "Chinstrap", "Gentoo"], {value: "Gentoo", label: "Penguin species:"})) | ||
``` | ||
|
||
The value of `pickSpecies` (<tt>="${pickSpecies}"</tt>) can then be accessed elsewhere in the page, as a parameter in other computations, and to create interactive charts, tables or text with [inline expressions](./javascript#inline-expressions). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: seems like <tt>
has been deprecated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, it should be <var>
Co-authored-by: Cindy <[email protected]>
Co-authored-by: Cindy <[email protected]>
Will eventually include docs for:
Dash.bignumber docsAlso TODO:
Planning doc