-
Notifications
You must be signed in to change notification settings - Fork 3
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
Refactor resource map #203
Conversation
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.
Good steps to organizing all the different APIs.
I would suggest restructuring the services by entity type as well, instead of by request. For example, services/ApplicationService.ts
which would have all the createApplciation
, updateApplication
etc. code.
const RESOURCE_MAP = { | ||
[ResourceType.USERS]: UserResource, | ||
[ResourceType.GROUPS]: GroupResource, | ||
[ResourceType.APPLICATIONS]: ApplicationResource, | ||
[ResourceType.API_KEYS]: ApiKeyResource, | ||
[ResourceType.PERMISSIONS]: PermissionResource, | ||
[ResourceType.POLICIES]: PolicyResource, |
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.
Amazing seeing this cleaned up. As discussed, we may not even need this map anymore since we are going to implement custom UIs for each resource panel. Having the api for each resource separated out makes them much cleaner to read. good work. We can iterate on the methods they implement as we go.
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.
sounds good! yeah, i think as i go along i'll be able to make more sense of what is needed, it was hard to tell much with that giant file. Adding in typing as I go is really helping me parse out some of these methods that weren't making sense.
getChildList?: ( | ||
resourceType: string, | ||
childResourceType: string, | ||
id: string, | ||
) => Promise<IListResponse>; |
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.
I know you havent implemented this yet so it may be good timing to leave a comment on this interface...
this is applicationInterface.getChildList
so we definitely don't need the resourceType
as an argument. Maybe we want to reorganize it like:
interface ApplicationResourceInterface {
... stuff
getChild: {
groups: (applicationId: string) => Promise<IListResponse<Group>>;
users: (applicationId: string) => Promise<IListResponse<User>>;
... etc
}
}
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 interface change probably also applies to other resources...
src/common/resources/group.ts
Outdated
import { GroupWithMask, PolicyWithMask } from 'services/types'; | ||
|
||
interface GroupResourceInterface { | ||
createItem: ({ item }: { item: Partial<Group> }) => Promise<Group>; |
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.
I don't think Partial<Group>
is sufficient type here... there are a specific set of required fields that must be provided to call this method.
The type you want for this maybe looks like:
type CreateGroupInput = {name: string} & Partial<Group>;
specify the required fields and their types then give it an Intersection (&) with the Partial Group to include all the remaining fields as optional.
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.
Oh i see what you mean, good idea - will do!
export interface GroupWithMask extends Group { | ||
mask: MaskLevel; | ||
} | ||
|
||
export interface UserWithMask extends User { | ||
mask: MaskLevel; | ||
} | ||
|
||
export interface PolicyWithMask extends Policy { | ||
mask: MaskLevel; | ||
} |
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.
why combine these instead of just passing the entity and the mask separately?
edit: i see your TODO comments. nevermind. 😨
enum FieldType { | ||
DROPDOWN = 'dropdown', | ||
INPUT = 'input', | ||
} |
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.
Once you build the views as components, not purely driven from schemas... Remember to delete this nonsense ;)
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.
Lol yes...for now i've left in this kinda stuff as reference, and I'll 🔥 it once I get the components done 🙂
First step in refactoring the resource map content.
Creates resource folder with a file for each resource type
Creates a schema folder with a file for each resource type. I left the previous content panel fields schema in each file for reference when I work on the resource content display components.
Adds types for create, delete and update service calls. Some of these types will be updated as the methods are refactored. (See ticket #204)
Adds TODOs and comments for next steps and found issues.
This branch will not build yet, very WIP!