Test webhooks & fixes #48
Conversation
* fix podman-compose cmd in readme. * Bind keycloak private to localhost in podman, otherwise WF fails to bootstrap * warning re cached postgres data * warning re cached npm modules
…th to link a new webhook to a particular test
…x.persistence.NoResultException is not thrown
| }} | ||
| aria-label="Event Type" | ||
| > | ||
| {eventTypes.map((option, index)=>{ |
There was a problem hiding this comment.
So you can select test/new here as well?
There was a problem hiding this comment.
Ah yes, that doesn't make sense, will fix that
| setTestWebHooks(response.map((h: Hook) => { | ||
| let hd: Hook = { | ||
| ...h, | ||
| id: Number(h.id), |
There was a problem hiding this comment.
Just wondering, why are those explicit type casts needed here?
There was a problem hiding this comment.
idk if they are explicitly required, iirc the IDE was not resolving the correct type but that is probably an issue with the IDE rather than the type could not be inferred at runtime. I can look at removing the type cast
There was a problem hiding this comment.
response array is result of a call to fetchApi() which returns a Promise<Any>. so response.map((h: Hook) requires the typecast, unless we want to include return type as a param to fetchApi(). That would be quite an intrusive change. Explicitly casting let hd: Hook can be dropped.
| @@ -129,6 +136,10 @@ export const reducer = (state = new TestsState(), action: TestAction) => { | |||
| state.byId = state.byId?.set(action.testId, { ...test, defaultView: action.view }) | |||
| } | |||
| } | |||
| break; | |||
| case actionTypes.UPDATE_HOOK: { | |||
| //TODO: define state changes | |||
There was a problem hiding this comment.
I must admit that I am not entirely sold on storing a cached copy of the database in the browser, especially when a part of the object might not be loaded (and there's not a clear distinction between not-loaded and not-set-at-all from the typesystem POV), but we should be consistent.
There was a problem hiding this comment.
This TODO comment might be out of date. I thought the whole premise of redux is to enable easy tracking of state (which involves caching on client side), otherwise you need to manage gui state CRUD operations manually
I did think about this, but there might be a use case where a tool might want to register for all events of a particular type. Also, the "test/new" event is fired when a new test is created, so in order to respond to those events that could not be related to an individual test. |
This PR introduces a number of changes, fixes and enhancements;