---
# System prepended metadata

title: Shared Scratchpad

---

# Shared Scratchpad



# Questions



### Q: where did you start?

- lots of clarity comes from seeing an end-to-end flow.
- started with modifying an example
- what's the smallest change I could make to implement the feature?
- insight: "Data Values File" is "just" a collection of `--data-value` invocations
- overlays are — in theory — a collection of operations over a document
- 


### Q: what gave you confidence that the `or_add` kwarg was the "right" approach?

- during writing proposal, talked about using overlay functionality as an "implementation detail" for this feature... so why not start there?
  - we're not going to leak to the user that we're doing this.
- this improvement to overlays is something that DK has been mulling over for some time.
- alternative approach (if decided didn't want to expose generally), `__or_add_internal` or somesuch.
- 


### Q: How far into the proposal is this PR?

Covering the core feature set: the --data-values-file


Does not cover:
- required playground enhancements
- 

### Q: How are you tracking where you are (and what you have left to do)?

- I'll come up with a high-level design and try it out.
- Sometimes you find out that it sucks for some reason and want to throw it away.
- In this case, there weren't a lot of controversial design elements.
- As a need arises, look locally for the improvement to existing mechanism
    - e.g. `@overlay/replace` replaces the entire value; considered `or_add` to extend it to meet these new needs.
    
### Q: What does "playing around" with a design mean?

- one question is, "how can I use the thing, myself?"
- exploratory testing... as soon as possible... sketch it out... how does this flow feel... from the user's perspective?
   - this is about stepping back as soon as there's something running.
- for example, I discovered what might happen if the user has trailing comments in a document, it would inadvertently erase the data values.
- not using tests to design layers; writing that directly.
- bring in tests as risk becomes obvious.

when paining (by analogy)
- start with pencil "scaffolding"
- work in layers of details to add.


### Q: Did you write comments for this review session, or do they help you keep context while coding?

- over the years, DK himself, has become to value comments more.
    - they give the reader "that little nudge" towards understanding the overall flow
- want to be able to "speed read" the code, not line-by-line; getting the gist
    - whitespace can convey "sections"
    - comments can convey a "heading" of sorts
    - looking for abstract layers/concepts
- put this in for the "reader", not polish for this Tech Forum, session.
- will use comments to "pseudo coding"




- "Long" methods
    - in Go, there's quite a bit of boilerplate for error handling
    - 


## Topic: Dependency Injection

- whereas in many other places in ytt, we're injecting whole `struct`s, here we're including a few functions.
- in `DataValuesFlags` note `EnvironFunc` and `ReadFileFunc`
- `iofs` package might be a baked abstraction.


















