From e89301805c095e3f8797927d641960e4b88557ad Mon Sep 17 00:00:00 2001 From: Sander Date: Sat, 14 Dec 2024 17:56:51 +0100 Subject: [PATCH] update feedback file --- FEEDBACK.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FEEDBACK.md b/FEEDBACK.md index 7ee7cdf..fb21407 100644 --- a/FEEDBACK.md +++ b/FEEDBACK.md @@ -33,7 +33,7 @@ Mostly API-level stuff, pet-peeves, OCD stuff, things I wish (as a developer) we - [ ] 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. -- [ ] `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: +- [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: ``` /**