update feedback

FEEDBACK.md

@@ -29,8 +29,8 @@ Ninja-level nodes:
 Mostly API-level stuff, pet-peeves, OCD stuff, things I wish (as a developer) were easier to do.
 
 - [ ] adding a new node requires quite some boilerplate, I see myself copying and pasting quite a lot of stuff from other components.
-- [ ] somewhat incoherent API, for example when I needed an attribute value I expected a function like `const value = useNodeAttribute<OscillatorData>(id, 'period', 0);`, but it turns out it was a lot easier and all I needed was `const { id, data } = useNode();` and then I could use the `data` object to fetch stuff from it like so `const waveform = data['waveform'];`. I prefer the way it is, but the inconsistency had me going around in circles for a while. It is slightly maddedning that intuition doesn't work in this codebase. I blame React for this, and the fact that some things have a more reactish API, while others are closer to the cleaner object model under it. I don't think there's an easy way to fix this that doesn't involve writing a ton of stupid wrappers. You probably do not feel any of this because React is second-nature to you by now. But for a React-virgin this way of doing things is weird.
-- [ ] more about coherence, Node properties are called Data in the code, Properties in some places, Settings in the `.tsx` file. Not a biggie but would be nice to settle on one word and name it the same across the entire codebase. I would propose *attributes*, because `settings` applies to too many things in app development and `properties` is more related to object-orientedness and can also get confusing.
+- [x] somewhat incoherent API, for example when I needed an attribute value I expected a function like `const value = useNodeAttribute<OscillatorData>(id, 'period', 0);`, but it turns out it was a lot easier and all I needed was `const { id, data } = useNode();` and then I could use the `data` object to fetch stuff from it like so `const waveform = data['waveform'];`. I prefer the way it is, but the inconsistency had me going around in circles for a while. It is slightly maddedning that intuition doesn't work in this codebase. I blame React for this, and the fact that some things have a more reactish API, while others are closer to the cleaner object model under it. I don't think there's an easy way to fix this that doesn't involve writing a ton of stupid wrappers. You probably do not feel any of this because React is second-nature to you by now. But for a React-virgin this way of doing things is weird.
+- [x] more about coherence, Node properties are called Data in the code, Properties in some places, Settings in the `.tsx` file. Not a biggie but would be nice to settle on one word and name it the same across the entire codebase. I would propose *attributes*, because `settings` applies to too many things in app development and `properties` is more related to object-orientedness and can also get confusing.
 - [ ] same thing about the words `Component` and `Node`, one has `BaseComponent.ts` in `@microflow/components` and `Node.tsx` in the presentation layer. You get used to it pretty quickly, and it makes some sense I guess, but makes the codebase a bit disorienting for a noob.
 - [ ] As an outsider non-React developer I would very much love if the model component `.ts` file and the presentation Node `.tsx` file where alongside each other in the project structure. I don't know how many times I had to fish out a file in the five-subfolder structure of the electron-app to change something that felt like it belonged in the model. Made me cringe in frustration a few times.
 - [x] `BaseComponent.ts` assumes that `change` happens when the value changes, but this is not always true. When writing the `Trigger` node I found situations were I wanted to send an output signal that didn't have a specific value. In the end I settled for sending out a 1.0 for `trigger happened` (or `bang` as it's called in other flow-based languages) and a `0.0` when `trigger didn't happen`. My first implementation was like this: