-
-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Labels
refactoringRefactor, improve code quality, pay tech debtRefactor, improve code quality, pay tech debt
Description
Current structure of modules is a bit messy:
GitHub
GitHub.Author
GitHub.Connection
GitHub.GraphQL
GitHub.Id
GitHub.Issue
GitHub.Label
GitHub.Lens
GitHub.Milestone
GitHub.Order
GitHub.PullRequests
GitHub.Render
GitHub.Query
GitHub.Repository
GitHub.RequiredField
GitHub.Title
GitHub.UserCurrent problem is that we have fields for different types (title of issue, login of user, etc.) and we also have different connections with input parameters (issue by state, pullrequests, etc.). Some connections can be polymorphic, so to abstract further, it's better to separate types.
I propose a new structure with clearer boundaries (and probably avoiding recursive dependencies).
I will write in a shorter syntax for clarity. Mostly duplicates the GitHub API structure:
GitHub
Types
Connection
Issue
Milestone
PullRequest
User
Id
Connections
Labels
Issue -- issue by number
Issues -- list of issues
PullRequests
Milestones
Interface
Actor -- has author name
Enums
IssueState
PullRequestState
IssueOrder
Queries
Repository
Viewer
Mutations
CreateIssue
AddAssigneesToAssignable
GraphQL
Query
Mutation
Render
API -- calling remote API, better name needed
Common
Query
Mutation
Abstraction -- local abstractions for better UX and UI, better name needed
Lens
Author -- HasAuthor typeclass and instances
Title -- HasTitle typeclass and instances
RequiredFieldWith this structure, it's clear what to add and where:
- All new types go to
GitHub.Types. - All new connections for those types use types and go to
GitHub.Connection - New read-only queries and mutations go to the corresponding sections.
- Functions to call GitHub API are in the
GitHub.APImodule. - Our local helpers in
GitHub.Abstraction
vrom911
Metadata
Metadata
Assignees
Labels
refactoringRefactor, improve code quality, pay tech debtRefactor, improve code quality, pay tech debt