Conversation
# Conflicts: # src/hooks/properties.ts # src/redux/store.ts
… visibility in redux
…cene graph nodes as well
…t need to subscribe anymore
This is not guaranteed to run after the propertyowners are added
|
Fixed the reported issues now - layers + adding and removing scene graph nodes should now work. OpenSpace/OpenSpace#3868 is not going to be fixed with this PR as it is related to an issue with the |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 76 out of 76 changed files in this pull request and generated 14 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| effect: () => { | ||
| unsubscribe(); | ||
| } |
WeirdRubberDuck
left a comment
There was a problem hiding this comment.
Here are some more comments.
I think that the checkbox fading should be brought up during a team meeting just to verify that everyone thinks this change is a good idea, but otherwise, I don't really have many comments
Did some testing and could not find any issues. I will also try a two-node setup locally on my machine and do some testing in the dome
| properties.forEach((p) => { | ||
| propertiesMap[p.uri] = p; | ||
| }); |
There was a problem hiding this comment.
I see your point - it makes sense 👍 would be great if we came to a consensus on a style to use and stick to that everywhere
| const properties = useAppSelector((state) => propertySelectors.selectEntities(state)); | ||
| const propertyOwners = useAppSelector((state) => | ||
| propertyOwnerSelectors.selectEntities(state) | ||
| ); |
There was a problem hiding this comment.
Thanks for the details! 🙏
My general feeling is that having the hooks would be worth it, at least in the places where we get all properties or property owners. It's a lot easier to read a hook that says, for example, allProperties and allPropertyowners instead of these two lines
const properties = useAppSelector((state) => propertySelectors.selectEntities(state));
const propertyOwners = useAppSelector((state) => propertyOwnerSelectors.selectEntities(state));But this might be biased on how often we had to e.g. get all properties before, and just not being used to the new "entities" concept. So I'm open to discussion and being convinced otherwise
What do you think @engbergandreas ?
| if (visibility === 'Fading' && fade !== undefined) { | ||
| return ( | ||
| <ActionIcon size={20}> | ||
| <RadialSweepIcon value={fade * 100} background={'transparent'} size={20} /> |
There was a problem hiding this comment.
Do we want to discuss it during a meeting? To make sure? Considering that it's a relatively big visual change, and it changes the "instantaneous" feeling of clicking the checkbox, it might be good to get more opinions
The new "fading" checkbox is not as much of a visual change, but I found it a little confusing when enabling/disabling multiple things in sequence. The visual feedback is slightly delayed, which is quite noticeable
Co-authored-by: Emma Broman <emma.broman@liu.se>
Co-authored-by: Emma Broman <emma.broman@liu.se>
…Space/OpenSpace-WebGui into feature/property-tree-topic
A bunch of performance optimizations regarding the data passing to and from the UI with the purpose of doing a long-term solve for the UI meltdown.
So for testing, try and make the meltdown happen!
entityAdapters. This is because we were pretty much implementing that anyway, but now we can instead rely on RTK and get some nice selectors generated for us.PropertyBatcherclass. This essentially functions as a throttle, but without the risk of missing values.To be used with engine PR
Some future work:
useAppSelector. This is suboptimal as whenever any property changes, this will trigger a re-render. I started to look into this but this PR is big enough as it is. Also I think it will require a big refactor of the scene tree hooks. To extract all propertyOwners is not as bad, as the propertyOwner state doesn't change that often.connectionMiddlewareinstead of the middlewares for the topics. Now, all of them fire ononConnection, but we don't have a lot of control over which fire first. This would help to make the UI feel way snappier on startup, probably by first getting the property tree as it basically freezes everything for a bit.Recommended reading: https://redux-toolkit.js.org/api/createEntityAdapter
Edit:
PropertyBatcheris therefore renamed toBatcher