I'd like to propose a format for part of the audit log endpoint. Right now, the way the old front-end works, he string is generated on the back-end such as writeln!(f, "Deleted invite {key:?}")?
To have more options on the front-end, I'd like to split this into an object. The back end could just return the action type and we could store all the language on the front-end.
{
user: "dolanske",
type: "delete-invite", // `consume-invite`, `create-invite` and so on
key: "quotes-dev",
}Now with items which iterate render HTML, simply return an array of the previously defined user/body/key objects. Now this is just an idea, I would assume you have better idea how to split it to offer some formatting liberty.
{
...
items: [] /* Array of sub-items */
}Having all the available types and their interfaces defined on the back-end and generating their typescript bindings would significantly improve the DX.
I'd like to propose a format for part of the audit log endpoint. Right now, the way the old front-end works, he string is generated on the back-end such as
writeln!(f, "Deleted invite {key:?}")?To have more options on the front-end, I'd like to split this into an object. The back end could just return the action type and we could store all the language on the front-end.
Now with items which iterate render HTML, simply return an array of the previously defined user/body/key objects. Now this is just an idea, I would assume you have better idea how to split it to offer some formatting liberty.
Having all the available types and their interfaces defined on the back-end and generating their typescript bindings would significantly improve the DX.