-
Notifications
You must be signed in to change notification settings - Fork 161
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
Enhance Local State Management with Instant Feedback via Client-Side Input Tag #148
base: main
Are you sure you want to change the base?
Changes from 1 commit
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 |
---|---|---|
|
@@ -311,6 +311,7 @@ def format_match(cond: str | Var, match_cases: List[BaseVar], default: Var) -> s | |
|
||
def format_prop( | ||
prop: Union[Var, EventChain, ComponentStyle, str], | ||
tag_name='', | ||
) -> Union[int, float, str]: | ||
"""Format a prop. | ||
|
||
|
@@ -349,7 +350,33 @@ def format_prop( | |
|
||
chain = ",".join([format_event(event) for event in prop.events]) | ||
event = f"addEvents([{chain}], {arg_def}, {json_dumps(prop.event_actions)})" | ||
prop = f"{arg_def} => {event}" | ||
|
||
if tag_name.startswith("Input_"): | ||
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. Same as the other instance of this? Why handle basis |
||
if isinstance(event, str): | ||
event = event.strip("{}") | ||
|
||
parts = chain.split('.') | ||
formatted_chain = f'{parts[0]}.{parts[1]}.{parts[2]}' | ||
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. Could it be possible that parts array is empty? This would break then, right?
Comment on lines
+355
to
+359
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. Added comment explaining what this part does and why. |
||
|
||
# Extract "_e0.target.value" | ||
value_match = re.search(r"value:([^,)}]+)", event) | ||
if value_match: | ||
value = value_match.group(1) | ||
|
||
# Extract "state.state" | ||
message_match = re.search(r"addEvents\(\[\S+?\(\"([^.]+?\.[^.]+)", event) | ||
if message_match: | ||
message = message_match.group(1) | ||
|
||
dispatcher_line = f"const dispatcher = dispatchers['{message}'];\n" \ | ||
f"dispatcher({{ message: {value} }});" | ||
|
||
prop = f"{arg_def} =>{{ {dispatcher_line}\n{event} }}" | ||
|
||
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. The logic added for handling
|
||
# Handle other types. | ||
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 other types? Ideally you should just create a string in the conditional and then inject that string in prop as assigned below. What do you think? |
||
else: | ||
# prop = f"{arg_def} =>{{ {dispatcher_line}\n{event} }}" | ||
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. Remove if not required. |
||
prop = f"{arg_def} => {event}" | ||
|
||
# Handle other types. | ||
elif isinstance(prop, str): | ||
|
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 conditional addition of a closing brace
}
torendered_chain
based on thetag_name
starting with "Input_" seems like a workaround for a specific case. This approach might introduce maintenance challenges and unexpected behavior for future components or changes.Consider implementing a more generic solution that ensures
rendered_chain
is correctly formatted for all components, possibly by reviewing howrendered_chain
is constructed and used across different component types.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.
+1 to this, why do we do this? Instead, this should have been handled basis
value
prop as we discussed initially. Am I missing something?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.
@akshatbhargava123, you're right to question the specific handling for components starting with "Input_". This was indeed a workaround for a particular case, which might not be the best approach for maintainability and consistency across different components.
The initial idea to handle this based on the
value
prop could provide a more generic and robust solution. This approach would ensure thatrendered_chain
is correctly formatted for all components, focusing on the actual properties and behavior of the components rather than their naming conventions.I'll review the implementation details and consider how we can adjust this to align with the initial discussion about the
value
prop. This might involve a more in-depth analysis of howrendered_chain
is constructed and ensuring it's appropriately formatted for all scenarios, not just specific cases. Thank you for bringing this to attention, and I'll work on identifying a solution that adheres to our initial agreement and improves the code's maintainability and consistency.