-
Notifications
You must be signed in to change notification settings - Fork 229
feat: apply initial layout COMPASS-9432 #7047
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
base: main
Are you sure you want to change the base?
Conversation
783340f
to
710bb2e
Compare
The layouts work much better now with the dimensions fixed 🎉. But still not exactly as imagined. For example the screenshot is LEFT_RIGHT - I thought this would spread to more columns. STAR creates one column only. Are we doing something wrong or is this expected result? @lchans |
9f586d2
to
11bfe02
Compare
036be24
to
a4d96d8
Compare
expect(store.getState().diagram?.edits.current).to.have.lengthOf(1); | ||
}); | ||
const renderResult = renderWithConnections( | ||
<Provider store={store}>{component}</Provider>, |
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 have helpers for this in compass-testing-library, I strongly suggest you take a look at those. We added these specifically so that we don't need to spend time for similar setup all the time and so that making changes to the plugin internals is easier in the long run (otherwise every time we tinker with plugin system ALL tests might need to be updated accordingly). If those doesn't cover some case you are trying to cover here, please shout this out so that we can provide tools covering those and keep the benefits of a shared testing harness
@mabaasit FYI as you added some helpers here initially.
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 was an issue i was facing when setting this up, but i don't remember exactly what it was (my guess is TestMongoDBInstanceManager
props were not being picked up and it does not support multiple connections). As a result, I had to add testConnections
in this file and mock connections
implementation.
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.
Updated the tests helpers in this file, haven't run into any problems 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.
For now I avoided the problem with store not being fit for that view by replacing the error by empty result. Possibly something we could use in the future - to allow some preparation of the store before rendering the component. We could also provide initial store state but seems more natural (and easier to maintain) to get there with actions.
void applyInitialLayout(storedNodes); | ||
return; | ||
} | ||
setNodes(storedNodes); |
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 state itself is not an effect here, this is state derived from model, only applying initial layout is an effect
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.
So this used to be a memo, I changed it to effect so that unpositioned nodes can be ignored (setNodes is not called in that case). Is it too weird? I was considering having a memo + boolean 'areNodesReady' tag as an alternative
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.
Yeah, it's almost always not a good idea to duplicate props to local component state through effects, especially when you have a clear way to derive this, so much so that React has a documentation for that:
When something can be calculated from the existing props or state, don’t put it in state. Instead, calculate it during rendering.
So nodes + areNodesReady + effect that depends on areNodesReady is definitely a cleaner way to do this.
There is honestly an argument to be made about moving this logic to the action itself as it doesn't really depend on UI (meaning actual DOM), is not really doing any application (more specifically it's not really an effect as compared to fitToView for example) just calculates the values for the state that is already in the store and so splitting this logic between React and Redux doesn't give us any meaningful separation of concerns here, while requiring us to jump through some unnecessary hoops to get the state in the right shape. This is a bit of splitting hairs thing, so I think it's fine if we keep it as is and just remove the unnecessary UI state from the equasion.
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.
Updated
packages/compass-data-modeling/src/components/diagram-editor.tsx
Outdated
Show resolved
Hide resolved
packages/compass-data-modeling/src/components/diagram-editor.tsx
Outdated
Show resolved
Hide resolved
packages/compass-data-modeling/src/components/diagram-editor.tsx
Outdated
Show resolved
Hide resolved
'LEFT_RIGHT' | ||
); | ||
setNodes(positionedNodes); | ||
onApplyInitialLayout( |
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 are supposed to also fit diagram into view after initial layout gets applied, right? I'm not seeing this happening at the moment
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.
Thank you, added!
2ef8837
to
235ab17
Compare
}, | ||
}; | ||
(require.cache[require.resolve('@mongodb-js/diagramming')] as any).exports = | ||
mockDiagramming; |
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 guess this isn't possible with something like sinon? Would it be possible/make sense to add a TODO to make the diagramming package itself allow mocking the relevant parts à la dependency injection?
It's a bit unfortunate to have this here, especially because it only targets a single test file right now, but all test files in the same mocha
invocation will have these mocks in place
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.
Ah. I was writing to explain that sinon wouldn't be enough because there was a problem with ESM/CJS interop. I actually spent some time trying to get a test setup that would import the Diagram correctly before I decided that mocks are fine as we cover the integration in e2e tests.
But as I was writing it hit me that even though the cause was the messed up import, no error was thrown until the imported piece was being used. So taking over the require was an overkill.
Tldr: actually sinon works, thanks for making me rethink!
packages/compass-data-modeling/src/components/diagram-editor.tsx
Outdated
Show resolved
Hide resolved
packages/compass-data-modeling/src/components/diagram-editor.tsx
Outdated
Show resolved
Hide resolved
Co-authored-by: Anna Henningsen <[email protected]>
bb093ab
to
c14faac
Compare
Description
[-1, -1]
applyLayout
from the diagramming lib to position the nodesChecklist
Motivation and Context
Open Questions
Dependents
Types of changes