GregoryConrad / rearch-dart

Re-imagined approach to application design and architecture
https://pub.dev/packages/rearch
MIT License
92 stars 4 forks source link

Feature Function / Capsule Creator / Effect Generator GUI #71

Closed jtkeyva closed 10 months ago

jtkeyva commented 10 months ago

Would be interesting to make a GUI where you can build and connect functions & features etc. in a schematic type of interface or IFTTT connectors without coding. Could be a way to transition/train people into FP as they can build complex blocks and see how they interconnect and then see how the functions were generated.

GregoryConrad commented 10 months ago

I’m not really sure what this would look like—connecting capsules in a GUI seems like it would be difficult because you don’t know how they may be transformed. Composing side effects may be more doable, but even that is a little iffy since there can be a lot of variance. Both would be pretty minimal, and I’m not sure it’d help enough.

more doable would be a devtool that analyzes a project and spits out a graph view of the capsules at play and their side effects. That seems like a lot of work though, so I’m not sure I’m up for it personally.

jtkeyva commented 10 months ago

yeah i hear that. maybe a vscode plugin with simple inputs. actually how about just making a brick? https://brickhub.dev this way you are stepped through a series of questions and options of what you want to achieve and it generates the code into an actual dart file. i dunno, just thinking how to make things a bit faster and easier cuz i'm just a hack haha

GregoryConrad commented 10 months ago

It's a bit difficult since capsules are pretty minimal in terms of boilerplate as-is. A big issue is how you want to expose your capsule's API via code, which I don't think can be effectively done via code gen. I believe you are familiar with BLoC, so here's an analogy: it's like the code gen will need to write all of the on(event)s (or whatever the syntax is), which wouldn't be plausible since that is code that we must write because it can vary and requires human intelligence to design it.

I think code gen or bricks are great for boilerplate, but as-is, essentially every part of a capsule is important and can be meaningfully configured. You start with the type of the capsule (return value), then the capsule's name, then the only bit of boilerplate, (CapsuleHandle use), followed by the function's body which can't easily be done via code gen.

You could make a brick for a trivial (state, setState), but this alone is already a one-liner:

(int, void Function(int)) myStatefulIntCapsule(CapsuleHandle use) => use.state(0);
// ( the capsule type...) theCapsuleNameFooBar(theOnlyBoilerplate) => what we return;

And even then, it is a best practice to return functions that don't just setState, but rather wrap around setState to make the API more tailored toward the data.

I think a better option would be a new documentation page that details the thought process on creating new capsules. I will track that in https://github.com/GregoryConrad/rearch-docs/issues/5

jtkeyva commented 10 months ago

Yes makes sense as there is little boilerplate.

It's the logic that needs to be learned and ingrained. So yeah, a step-through infographic or animation or video on how to design the logic for us dummies could go a long way.

BLoC takes some time before it clicks and you get that aha moment of how it works. I can see how ReArch could do the same. I just haven't had time to sit down and "figure it out" quite yet. But maybe some simple or familiar terminology like "nested functions" triggers, watchers, listeners could help dumb it down a bit.