itemconsulting / enonic-fp Goto Github PK

Add TypeScript wrappers for

• getPhrases
• getSupportedLocales
• localize

When part of a pipeline, ContextLib.run should be able to take the parameters piped in, and pass it on to the inner function.

We know that Content.page.config is of the type generated by enonic-wizardry. We should be able to give that type up front.

Give Content.publish a type too.

Either add http status to EnonicError, or add a function that does the mapping.

Make the mapping between Throwable from Java, and EnonicError better

1. Get the message from the "root" Throwable
2. Add the stackTrace field to EnonicError

The following fields in Request should be able to be undefined, to force the developer to handle the undefined case:

• params
• headers
• cookies

To follow best practices for FP, data should be immutable by adding readonly to properties. And use ReadonlyArrays.

Add an unsafe version, that can be used when rendering error pages.

If the rendering fails, and we return a Either<EnonicError, T>, we can end up with a endless loop, and stack overflow.

It's a bit funky, but we'll give it a shot.

Because of naming conflicts, it might make coding nicer, if we change the names of the interfaces in common.

• Error (biggest problem, since there is a global Error already)
• Response
• Request

• Build to top level project
• Update usage documentation
• Add how to localize errors in README.md
• Ensure that EnonicError-objects can be extended
• Strategy for testing this library
• Online documentation of problems
• Pull out all error messages in Stacktrace
• Don't render Exception details when req.mode === 'live'
• Release a Beta and try out new code

"BadRequestError" should be able to hold an object of this shape with its errors

{
  "firstName": ["Is required", "Must be capitalized"]
}

The functions in the Enonic libraries that would return void, should now return Either<Error, void> instead of Either<Error, boolean>

Require count to be specified, since the default is 10 (and this can create bugs)

When parsing exceptions we should extract the stack trace from it if the stack trace exists.

We should look into how we want to return the errors from validation. Maybe the cause field should be able to take a datastructure containing the errors.

To make the functional actually be pure, we should returns IOEither, since we are actually doing IO operations.