idea dumps #855

jenbutongit · 2022-06-19T17:19:46Z

jenbutongit
Jun 19, 2022
Maintainer

Question library #675
pre and post hooks for webhooks
- prehooks can modify data before it is sent to a webhook
- posthooks can modify or do additional actions after a reference is sent. (i.e. send a notify message with the received reference number)
make better use of hapi api
- each form should be initialised in it's own realm https://hapi.dev/api/?v=20.2.2#-serverrealm. it will let us do nice things with vhost. you will then be able to apply different plugins or extension points to different forms.
- "static" mode
  - for production environments, it doesn't make sense to create a route or do a object lookup (server.forms[formId]) every time it is hit. as a first pass we can do "lazy" inits
  - as it stands, by using make[Get|Post]Route, we can't use hapi extensions to modify behaviour of specific routes.
  - spike into how apps implementing can extend the app easily. perhaps we go back to distributing this as a package as well?
use computational graphs to determine if routes are accessible or not (for/while loops are just hard to read and have always been finicky/complex logic when they've already been solved by graphs)

allow graph view and side-by-side view
- side-by-side view will display the page edit or component edit pages, and the preview on the right
graph navigation by arrow key
refactor conditions. this whole thing is a mess. doesn't follow any react patterns or frontend js patterns. class components are dangerously stateful at present (interferes with react rendering and very difficult to see what is going on.. tightly coupled.. I can go on)
designer API, hoist all reducer actions to an API
- by doing this we can then move away from react or use a more non-js friendly framework (like next.js), or migrate to another

refactor conditions (this will haunt me FOREVER)
- at the very least, we should try to use joi.ref instead of creating "hard" links to component names