Replies: 3 comments
-
Actions can come from: Primary Client Peer Client Kernel Server |
Beta Was this translation helpful? Give feedback.
-
Identify State Transitions and Actions/Expected Behavior |
Beta Was this translation helpful? Give feedback.
-
So the complication here is that Jupyter traditionally thinks of the browser as the source of truth. This means there's multiple lines of communication about actions taken. Keeping the UI messaging similar to Jupyter Classic is probably a good default for the final status. This means the final state should probably match into the redux store but different actions should be isolated. The primary issue I believe will be around the fact that |
Beta Was this translation helpful? Give feedback.
-
It looks like the kernel.status stored in the redux store is used both to represent the client action (Restarting | Starting) for the kernels as well as the actual status reported by the kernel. Reference
nteract/packages/reducers/src/core/entities/kernels.ts
Line 51 in df958a9
Was wondering if it was better to represent these states separately or have kernel status only represent what the server returns over the channel or on launch and have a separate entity to track the client action? The reason is because it feels like one would mask the other. Some scenarios I can think of:
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions