Exposing External Prop For Dynamic Planner And Live Mode Switching In Course Scheduler

Hey guys! Ever wished you could switch between different modes in your course scheduler? Well, in this article, we're diving deep into how we can dynamically switch between Planner and Live modes. We'll break down the problem, explore the current behavior, discuss the desired behavior, and walk through the proposed solution. Plus, we'll cover the acceptance criteria and references. So, buckle up, and let's get started!

The Problem: No Dynamic Mode Switching

Previously, the user interface for switching between Planner and Live modes was available, but it's been removed. This has left the grid component stuck in planning mode. The core issue is that there is currently no way to dynamically control this mode from outside the component. This prevents users from switching between live and planner modes at runtime, which can be a real pain. Imagine needing to toggle between planning and live views but being stuck in one mode – frustrating, right?

To really understand why this is a problem, let's dig into the specifics. The SchedulerGrid.vue component, which is central to our scheduling interface, contains a hardcoded isLiveMode = ref(false). This means it's always in planning mode. The comment next to this line says it all: "Always in planning mode (no mode switching)." Ouch! To make matters worse, the component doesn't accept a controlling prop for the mode, so there’s no way to tell it to switch from the outside. This rigidity severely limits the flexibility of the application.

Another part of the puzzle is wwElement.vue. This component passes is-read-only based on publishedBy, but there’s no bindable property to externally force Planner vs. Live mode. This means even if we wanted to hack our way around the hardcoding in SchedulerGrid.vue, we’d hit a wall here. Finally, ww-config.js, which should be the place where we set up configurations, doesn’t expose a property for Planner/Live mode either. This is a critical piece missing from our mode-switching puzzle.

In summary, the absence of a dynamic control for Planner and Live modes forces users into a single, inflexible view. This not only limits functionality but also degrades the user experience. For a feature as fundamental as mode switching, this is a significant drawback that needs addressing. We need a solution that allows us to toggle between modes seamlessly and efficiently.

Current Behavior: Hardcoded Planning Mode

Let's take a closer look at what's happening right now. The current behavior is quite straightforward, but not in a good way. As mentioned earlier, SchedulerGrid.vue is hardcoded to planning mode. This means that no matter what we do from the outside, the grid will always behave as if it's in planning mode. This is primarily due to the isLiveMode = ref(false) line and the lack of a controlling prop.

Specifically, SchedulerGrid.vue contains the following problematic line: isLiveMode = ref(false). This line, combined with the comment "Always in planning mode (no mode switching)," makes it clear that the component was intentionally designed to operate solely in planning mode. While this might have been a temporary measure or a design decision at some point, it now restricts the application's ability to function in live mode without modification. The absence of a prop to override this setting is a crucial oversight that needs rectification.

Furthermore, wwElement.vue passes is-read-only based on the publishedBy property. While this is useful for distinguishing between published and draft schedules, it doesn't provide a general mechanism for switching between Planner and Live modes. The issue here is that there's no way to externally force the component into either Planner or Live mode. The is-read-only property is tied to a specific condition (publication status) rather than a general mode setting.

Lastly, ww-config.js doesn't expose a property for Planner/Live mode. This is a significant omission because ww-config.js is typically where you'd expect to find such a configuration option. By not having a property here, we lose the ability to configure the mode at a higher level and pass it down to the components that need it. This lack of exposure further cements the hardcoded nature of the planning mode.

In essence, the current behavior can be summarized as a system where the Planner mode is the only option, enforced by hardcoding and a lack of external control points. This rigid setup prevents dynamic switching, which is essential for a flexible and user-friendly application. To move forward, we need to introduce a way to toggle between modes at runtime.

Desired Behavior: Dynamic Mode Control

Okay, so we've established the problem and the current limitations. Now, let's talk about the desired behavior. What do we want the system to do? Ideally, we want to expose a bindable property that allows us to switch between Planner and Live modes dynamically. This means being able to change the mode at runtime and have the grid update accordingly.

Specifically, we want to expose a bindable property, such as mode: 'planner' | 'live', in ww-config.js. This property should have a default value of 'planner' and a tooltip explaining its purpose: "Switch between Planner (editable draft) and Live (read-only published) modes." By exposing this property in ww-config.js, we make it accessible at a high level, allowing for easy configuration and control of the mode.

Next, in wwElement.vue, we need to accept the mode prop and compute an isLive boolean. This boolean will then drive the is-read-only property and be passed as a new prop to SchedulerGrid.vue. This ensures that the mode setting is propagated down the component tree, influencing the behavior of the grid.

In SchedulerGrid.vue, we need to add a prop for isLiveMode. This prop will determine which data source to use (draftSchedules vs. liveSchedules) and gate editing features appropriately. When mode is planner, the grid should use draftSchedules and enable editing features. Conversely, when mode is live, the grid should use liveSchedules and disable editing features, making it read-only. Critically, we need to remove the hardcoded planning mode in this component to allow for dynamic switching.

It's also essential to add a watcher for the mode prop in SchedulerGrid.vue. This watcher will ensure that changes propagate immediately, so the grid updates in response to mode changes. Without a watcher, there might be a delay or a failure to update the grid, which would undermine the dynamic switching capability.

Finally, we need to document the new mode prop and its expected usage in both README.md and AI.md. Proper documentation is crucial for ensuring that other developers understand how to use the new feature and can integrate it into their workflows.

In summary, the desired behavior involves exposing a mode property, propagating it through the component tree, updating the grid based on the mode, and ensuring that changes happen dynamically and are well-documented. This will provide the flexibility needed to switch between Planner and Live modes seamlessly.

Proposed Solution: Exposing and Propagating the Mode

Alright, let's dive into the proposed solution for dynamically switching between Planner and Live modes. This involves several key steps, including adding a new bindable property, modifying components to accept and propagate the mode, and ensuring that changes trigger immediate updates.

First and foremost, we need to add a new bindable property in ww-config.js. This property will be named mode, and it should be an enum with two possible values: 'planner' and 'live'. The default value should be 'planner', and we should add a tooltip that reads: "Switch between Planner (editable draft) and Live (read-only published) modes." This property will serve as the primary control for switching between modes at the application level.

Next up is modifying wwElement.vue. This component needs to accept the mode prop from ww-config.js and compute an isLive boolean. This boolean will then be used to drive the is-read-only property and be passed as a new prop to SchedulerGrid.vue. The computation of isLive might look something like this: isLive = computed(() => this.mode === 'live'). This ensures that the isLive property accurately reflects the current mode setting.

The heart of the solution lies in SchedulerGrid.vue. Here, we need to add a prop for isLiveMode. This prop will replace the hardcoded isLiveMode = ref(false) and determine which data source to use: draftSchedules when in Planner mode and liveSchedules when in Live mode. We also need to gate editing features based on this prop, enabling them in Planner mode and disabling them in Live mode. The crucial step here is removing the hardcoded planning mode to allow the prop to take effect.

To ensure that mode changes propagate immediately, we need to add a watcher for the mode prop in SchedulerGrid.vue. This watcher will trigger an update whenever the mode changes, ensuring that the grid reflects the new mode setting without delay. This might look something like: watch(() => this.isLiveMode, (newMode) => { /* Update grid based on newMode */ }). The watcher is essential for a responsive and dynamic mode-switching experience.

Finally, we need to document the new mode prop and its expected usage in both README.md and AI.md. This documentation will guide other developers on how to use the new feature and ensure that it’s properly integrated into the application.

In summary, the proposed solution involves exposing a mode property, propagating it through the component tree, updating the grid based on the mode, and ensuring immediate updates via a watcher. This comprehensive approach will enable dynamic switching between Planner and Live modes, enhancing the flexibility and usability of the course scheduler.

Acceptance Criteria: Ensuring the Solution Works

Now that we've outlined the proposed solution, let's talk about the acceptance criteria. These are the conditions that must be met to consider the solution successful. Think of them as our checklist for ensuring everything works as expected.

First and foremost, the new external property must be exposed and bindable in WeWeb. This means that the mode property in ww-config.js should be accessible and modifiable from the WeWeb interface. This is crucial because it's the entry point for controlling the mode externally.

Next, toggling the mode at runtime must update the grid immediately. This ensures that the dynamic switching functionality is working as intended. There should be no noticeable delay between changing the mode and seeing the grid update. This responsiveness is key to a good user experience.

In Live mode, the grid should be read-only and use liveSchedules. Conversely, in Planner mode, the grid should be editable and use draftSchedules. This ensures that the correct data source is being used and that the editing features are appropriately enabled or disabled based on the mode. This is a core requirement for the mode-switching functionality.

The mode-changed event should be emitted on mode switch. This event is important for other parts of the application that might need to react to mode changes. Emitting this event consistently ensures that other components can stay in sync with the current mode.

Finally, the documentation must be updated. This includes updating README.md and AI.md to reflect the new mode prop and its usage. Proper documentation is essential for ensuring that other developers can understand and use the new feature effectively.

In summary, the acceptance criteria ensure that the new mode property is accessible, that the grid updates dynamically, that the correct data sources and editing features are used, that events are emitted, and that the feature is well-documented. Meeting these criteria will guarantee that the solution is robust and user-friendly.

References: Key Components and Resources

To wrap things up, let's take a look at the references we've mentioned throughout this article. These are the key components and resources that are central to the mode-switching problem and solution.

First up is SchedulerGrid.vue. This component is where the hardcoded planning mode resides and where we need to implement the dynamic switching logic. It's crucial to understand this component's structure and behavior to make the necessary changes effectively. Specifically, we've noted the hardcoded planning mode and the previous UI toggle that was removed.

Next, we have wwElement.vue. This component passes the is-read-only property, but it lacks an external control for Planner/Live mode. We need to modify this component to accept the mode prop and propagate it down to SchedulerGrid.vue. This component acts as a bridge between the configuration and the grid.

ww-config.js is another key reference. This is where we need to add the mode prop to allow for external control of the mode. This file serves as the configuration hub for the application, and adding the prop here makes it accessible at a high level.

We also mentioned Pinia/simple state, which manages viewMode and entries. While this isn't directly related to the Planner/Live mode switch, it's part of the broader state management system in the application. Understanding how these different state management pieces interact can be helpful.

Finally, we've included a link to GitHub Search for more context. This allows you to dive deeper into the codebase and see how the mode-switching issue has been discussed and addressed in the past. It's a valuable resource for getting a comprehensive understanding of the problem.

In summary, the references provide a roadmap to the key components and resources involved in the mode-switching solution. Understanding these references is crucial for implementing the solution effectively and ensuring that it integrates well with the rest of the application.

By addressing these points and implementing the proposed solution, we can provide a much more flexible and user-friendly experience for managing course schedules. Thanks for joining me on this deep dive, and I hope you found it helpful!

In conclusion, dynamically switching between Planner and Live modes is a critical feature for enhancing the flexibility and usability of our course scheduler. By addressing the hardcoded planning mode, exposing a bindable property, and propagating mode changes through the component tree, we can achieve a seamless mode-switching experience. The proposed solution, coupled with the acceptance criteria and documented references, provides a clear path forward. Let's make it happen!