-
Notifications
You must be signed in to change notification settings - Fork 484
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
chore: remove (biased) event-handler subscription, preventing an event of having more than 1 handlers #3808
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -407,12 +407,12 @@ def tooltip_direction(self, value: Optional[TooltipDirection]): | |
|
||
# on_chart_event | ||
@property | ||
def on_chart_event(self): | ||
return self.__on_chart_event | ||
def on_chart_event(self) -> OptionalEventCallable["BarChartEvent"]: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. issue (complexity): Consider using methods to manage the event handler. The recent code change introduces additional complexity by directly accessing the |
||
return self.__on_chart_event.handler | ||
|
||
@on_chart_event.setter | ||
def on_chart_event(self, handler: OptionalEventCallable["BarChartEvent"]): | ||
self.__on_chart_event.subscribe(handler) | ||
self.__on_chart_event.handler = handler | ||
self._set_attr("onChartEvent", True if handler is not None else None) | ||
|
||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -168,12 +168,12 @@ def animate(self, value: AnimationValue): | |
|
||
# on_chart_event | ||
@property | ||
def on_chart_event(self): | ||
return self.__on_chart_event | ||
def on_chart_event(self) -> OptionalEventCallable["PieChartEvent"]: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. issue (complexity): Consider maintaining the original approach to manage event handlers. The new code introduces additional complexity by directly accessing |
||
return self.__on_chart_event.handler | ||
|
||
@on_chart_event.setter | ||
def on_chart_event(self, handler: OptionalEventCallable["PieChartEvent"]): | ||
self.__on_chart_event.subscribe(handler) | ||
self.__on_chart_event.handler = handler | ||
self._set_attr("onChartEvent", True if handler is not None else None) | ||
|
||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
import asyncio | ||
from typing import Callable | ||
from typing import Callable, Optional | ||
|
||
from flet_core.control_event import ControlEvent | ||
from flet_core.types import OptionalControlEventCallable | ||
|
@@ -8,11 +8,11 @@ | |
class EventHandler: | ||
def __init__(self, result_converter=None) -> None: | ||
self.__result_converter = result_converter | ||
self.__handlers = {} | ||
self.handler: OptionalControlEventCallable = None | ||
|
||
def get_handler(self): | ||
async def fn(e: ControlEvent): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. issue (code-quality): Add guard clause ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you mean? Explain detaily. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Certainly! The suggestion to "Add guard clause" refers to a common refactoring technique where you handle special cases or error conditions early in a function, allowing the main logic to be more readable and less nested. In this context, it means you should add a check at the beginning of the Here's an example of how you might implement a guard clause in the def get_handler(self):
if self.handler is None:
raise ValueError("Handler is not set")
async def fn(e: ControlEvent):
await self.handler(e)
return fn In this example, if |
||
for handler in self.__handlers.keys(): | ||
if self.handler is not None: | ||
ce = e | ||
if self.__result_converter is not None: | ||
ce = self.__result_converter(e) | ||
|
@@ -24,20 +24,9 @@ async def fn(e: ControlEvent): | |
ce.page = e.page | ||
|
||
if ce is not None: | ||
if asyncio.iscoroutinefunction(handler): | ||
await handler(ce) | ||
if asyncio.iscoroutinefunction(self.handler): | ||
await self.handler(ce) | ||
else: | ||
e.page.run_thread(handler, ce) | ||
e.page.run_thread(self.handler, ce) | ||
|
||
return fn | ||
|
||
def subscribe(self, handler: OptionalControlEventCallable): | ||
if handler is not None: | ||
self.__handlers[handler] = True | ||
|
||
def unsubscribe(self, handler: Callable[[ControlEvent], None]): | ||
if handler in self.__handlers: | ||
self.__handlers.pop(handler) | ||
|
||
def count(self) -> int: | ||
return len(self.__handlers) |
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.
issue (complexity): Consider maintaining the subscription pattern for event handling.
The new implementation of the
on_resize
property introduces additional complexity by directly accessing thehandler
attribute of__on_resize
. This approach violates encapsulation and increases coupling, making the code harder to maintain and understand. The original subscription model was more straightforward and intuitive. Consider maintaining the subscription pattern, which is likely more maintainable and aligns with common event handling practices. Additionally, ensure there is a clear way to unsubscribe handlers if needed. This will help keep the codebase clean and easier to work with in the future.