-
Notifications
You must be signed in to change notification settings - Fork 13
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
HubSiteManager & HubSites module #741
Conversation
Codecov Report
@@ Coverage Diff @@
## master #741 +/- ##
===========================================
Coverage 100.00% 100.00%
===========================================
Files 345 484 +139
Lines 6528 8374 +1846
Branches 1193 1410 +217
===========================================
+ Hits 6528 8374 +1846
Continue to review full report at Codecov.
|
@@ -53,7 +53,7 @@ | |||
"husky": "^4.3.0", | |||
|
|||
"jasmine": "^3.6.4", | |||
"jasmine-core": "^3.4.0", | |||
"jasmine-core": "3.4.0", |
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 was needed to resolve some FireFox test failures. I've opened #742 to look into this
hubApiUrl: this.hubUrl, | ||
}; | ||
} | ||
|
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.
We need to be able to create IHubRequestOptions
when not auth'd
serializeContentFilterForPortal, | ||
} from "."; | ||
import { ISearchResponse } from ".."; | ||
|
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.
Would appreciate input from @tomwayson on this - it all works - even after this is merged
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'm not sure what you are expecting not to work, but we definitely should not be importing from "."
and ".."
b/c of circular deps.
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.
was more the use of createContentEntitySearchFn
which holds a closure over a ItemToEntityFunction<T>
. It's really useful but a little complex. That said, the IHubItemEntity
interface now requires an fromItem(IItem):Promise<T>
which is the function needed in the closure... so... complex, but not random?
async create( | ||
site: Partial<IHubSite>, | ||
requestOptions?: IHubRequestOptions | ||
): Promise<IHubSite> { |
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.
Since this is a multi-step operation, I'm considering returning the IHubSite & OperationStack
but mulling how best to encapsulate that w/o it getting gross
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.
there's a lot of code here, so I only gave a cursory glance, esp w/ the tests. Main thing from my POV is to not export anything we don't need at the time of release in opendata-ui. We can always add exports to index.ts files later.
@@ -16,3 +16,4 @@ export * from "./get-structured-license"; | |||
export * from "./slugs"; | |||
export * from "./normalize-solution-template-item"; | |||
export * from "./setItemThumbnail"; | |||
export * from "./registerBrowserApp"; |
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.
does this need to be part of the external API? Is anyone ever going to use this fn on it's own, or just registerSiteAsApplication()
?
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.
needed b/c it's re-exported in sites package
export * from "./fetchSiteModel"; | ||
export * from "./get-site-by-id"; | ||
export * from "./HubSiteManager"; | ||
export * from "./HubSites"; | ||
export * from "./registerSiteAsApplication"; | ||
export * from "./site-schema-version"; | ||
export * from "./themes"; |
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.
ditto w/ all these - if we don't have a known place where we are going to call any of them from the Hub app, or hub-components, let's not export them. We can always export them later if needed. If we needlessly export them now it becomes very difficult to modify or remove them and adds to our maintenance costs.
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.
either needed directly or re-exported in hub-sites
serializeContentFilterForPortal, | ||
} from "."; | ||
import { ISearchResponse } from ".."; | ||
|
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'm not sure what you are expecting not to work, but we definitely should not be importing from "."
and ".."
b/c of circular deps.
There hasn't been any activity on this pull request in the past 3 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. If you want this PR to never become stale, please apply the "Draft" label. |
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.
thanks for making these fns internal-only.
I'm still wary of the from ".."
. I understand that it can cause mocking issues. The way I got around those w/ content was to move the shared fn out into it's own module, or a "lower level" module that could be safely import
ed by all consuming locations.
@tomwayson I'll see what I can do about those... fwiw - I believe that's what vscode does when you move files around / automatically add the imports vs manually typing the import |
yep, that's exactly what it does, which is unfortunate. I have already pulled this, and started fixing them locally, you want me to push what I have? |
HubSiteManager
class, and it's backingHubSites
module.sites
to theHub
class..search(..)
works for the Manager classes. They now delegate tosearchContentEntities(...)
which takes a conversion function that handles converting from an item to the entity type. These search functions only search against the Portal API - they never search using the Hub API..fromItem(IItem, requestOptions)
Note: The e2e's are intentionally brittle. They are not intended to be run in CI, but rather, are used during development / debugging to ensure the platform responds as expected. If we want to have ci-runnable e2e's we can add tasks to do that
Note Part Deux
FireFox tests failed in CI on this. Took a few hours of digging but the issue was due to rebuilding package-lock.json, which picked up
jasmine-core
3.99.0from
3.4.0. Forcing things back to
3.4.0` resolved the issue, and I created an issue to resolveCloses Issues: #3346
ran commit script (
npm run c
)For more information see the README