-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#IP-324] Change fp-ts version to 2.x and removed old italia-commons uses #154
Conversation
b1eb10d
to
30c405b
Compare
55c3b6c
to
ce0587e
Compare
@pagopa/danger-custom-rulesAuthor: Federico Feroldi Description: Shared rules for DangerJS, used in the Digital Citizenship projects Homepage: https://github.com/pagopa/danger-plugin-digitalcitizenship#readme
|
Created | 7 months ago |
Last Updated | 7 months ago |
License | MIT |
Maintainers | 5 |
Releases | 1 |
Direct Dependencies |
README
io-functions-express
Express adapter for Azure Functions.
Mostly a porting to TypeScript from azure-function-express.
New dependencies added: @pagopa/express-azure-functions
and @pagopa/danger-custom-rules
.
Example of PR titles that include pivotal stories:
- single story:
[#123456] my PR title
- multiple stories:
[#123456,#123457,#123458] my PR title
taskEither | ||
.of<ServicePreferenceError, ServicesPreferencesMode>( | ||
pipe( | ||
TE.of<ServicePreferenceError, ServicesPreferencesMode>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to write explicit types here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately in this cases TS cannot infer the Left type (since it's not defined), so we need to explicit it
/azp run |
No pipelines are associated with this pull request. |
Out of the scope of this PR, we must fix node version in |
return pipe( | ||
// check whether the client can create a message for the recipient | ||
TE.fromEither( | ||
canWriteMessage(auth.groups, authorizedRecipients, fiscalCode) | ||
), | ||
// Verify if the Service has the required quality to sent message | ||
TE.chain(_ => | ||
disableIncompleteServices && | ||
!incompleteServiceWhitelist.includes(serviceId) && | ||
!authorizedRecipients.has(fiscalCode) | ||
? TE.fromEither( | ||
pipe( | ||
ValidService.decode(userAttributes.service), | ||
E.bimap( | ||
_1 => ResponseErrorForbiddenNotAuthorizedForRecipient, | ||
_1 => true | ||
) | ||
) | ||
: fromEither(right(true)) | ||
) | ||
.chain(_ => | ||
// check whether the client can provide default addresses | ||
fromEither(canDefaultAddresses(messagePayload)) | ||
) | ||
.chain(_ => | ||
// check whether the client can ask for payment | ||
fromEither( | ||
canPaymentAmount( | ||
messagePayload.content, | ||
service.maxAllowedPaymentAmount | ||
) | ||
: TE.right(true) | ||
), | ||
TE.chainW(_ => | ||
// check whether the client can provide default addresses | ||
TE.fromEither(canDefaultAddresses(messagePayload)) | ||
), | ||
TE.chainW(_ => | ||
// check whether the client can ask for payment | ||
TE.fromEither( | ||
canPaymentAmount( | ||
messagePayload.content, | ||
service.maxAllowedPaymentAmount | ||
) | ||
) | ||
.chain(_ => | ||
// create a Message document in the database | ||
createMessageDocument( | ||
messageId, | ||
messageModel, | ||
auth.userId, | ||
fiscalCode, | ||
messagePayload.time_to_live, | ||
serviceId | ||
) | ||
), | ||
TE.chainW(_ => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think if we use only one TE.fromEither
pipe(
// check whether the client can create a message for the recipient
canWriteMessage(auth.groups, authorizedRecipients, fiscalCode),
// Verify if the Service has the required quality to sent message
E.chain(_ =>
disableIncompleteServices &&
!incompleteServiceWhitelist.includes(serviceId) &&
!authorizedRecipients.has(fiscalCode)
? pipe(
ValidService.decode(userAttributes.service),
E.bimap(
_1 => ResponseErrorForbiddenNotAuthorizedForRecipient,
_1 => true
)
)
: E.right(true)
),
E.chainW(_ =>
// check whether the client can provide default addresses
canDefaultAddresses(messagePayload)
),
E.chainW(_ =>
// check whether the client can ask for payment
canPaymentAmount(
messagePayload.content,
service.maxAllowedPaymentAmount
)
),
TE.fromEither,
TE.chainW(_ =>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way we are making that step synchronous, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, all the steps before TE.taskEither
will be executed on the pipe
creation and not when the TaskEither
is executed. IMHO is not a problem if the pipe
is used inside the execution context. Do you think this pattern could generate unwanted behaviors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only one I see is not taking full advantages of node event loop
Yes, I've found it set to a higher values, so I thought it was ok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM apart a few stylistic comments. Thanks @gquadrati for the amazing job.
List of Changes
Motivation and Context
Migrate to fp-ts v2
How Has This Been Tested?
alredy present unit tests
Screenshots (if appropriate):
Types of changes
Checklist: