def index() -> xt.Component:
    layout = xt.form(xt.vstack(
        xt.input(
            placeholder="Paste YAML code here",
            on_change=State.on_yaml_input_change,
            width="30%",
            height="300px",
        ), ),
        xt.button("Convert to Python", on_click=State.handle_conversion),
        xt.text(State.python_data, font_size="2em"),
        spacing="1em",
        align_items="center",
        justify_content="center",
        height="100vh",
    )
    return layout

Problem statement

when I type inside the input it shows

Feature

When I press enter it should go to next line

Recreate the Streamlit roadmap page using Nextpy. This will serve as a practical demonstration of Nextpy’s performance in a real-world application scenario. Use this recreation as a benchmark to quantify the performance differences between Streamlit and Nextpy.

def index() -> xt.Component:
    layout = xt.box(
        # xt.title("Resume Search App"),
        xt.file_uploader("Upload your resume", on_change=on_file_upload),
        xt.text_input("Enter the text which you want to search: ", bind="search_text"),
        xt.button("Search", on_click=search_resume),
        xt.stack(
            [xt.box(result, style={"margin_bottom": "10px"}) for result in xt.bind("search_results")]
        ),
    )
    return layout

May I kindly request that someone inform me of the appropriate attribute to upload the pdf or document file?

It's time to upgrade Nextpy to Pydantic v2. This migration is crucial to leverage the latest performance improvements and ensure compatibility with other libraries that are also moving to Pydantic v2.

Expected Benefits

• Performance Improvements: Pydantic v2 comes with significant enhancements in performance, which can positively impact the overall efficiency of Nextpy.
• Better Compatibility: Keeping up with the latest version ensures that Nextpy remains compatible with other tools and libraries in the ecosystem that rely on Pydantic.
• Access to New Features: Pydantic v2 introduces new features and improvements, which can be beneficial for future development and feature enhancements in Nextpy.

Potential Challenges & Blockers

• Dependencies on Other Libraries: Some dependencies like sqlmodel might have compatibility issues that need to be addressed.
• Internal API Changes: Pydantic v2 has made changes to some of its internal APIs (e.g., ModelField no longer exists). We need to find suitable alternatives or workarounds for these changes.

Call for Contributions

We invite contributors to join in on this upgrade process. Whether you have experience with Pydantic internals or are new to it, your input and help would be valuable.

• If you have experience with Pydantic v2 or its internals, your guidance can help overcome specific challenges.
• For those who are new, this could be a great learning opportunity and a way to contribute significantly to the Nextpy project.

Progress Tracking

• Assess the impact of migration on existing codebase
• Identify and resolve dependencies issues with sqlmodel
• Update the Nextpy codebase to adapt to Pydantic v2 API changes
• Thorough testing to ensure stability post-migration
• Update documentation to reflect changes

Collaboration and Updates

• For ongoing discussions, please refer to this thread.
• Contributors working on related tasks are encouraged to share updates and findings here.
• Any significant breakthroughs or challenges can be discussed in follow-up comments.

Conclusion

Migrating to Pydantic v2 is an important step for the future of Nextpy. It ensures that our framework stays up-to-date with the latest advancements and continues to integrate smoothly within the broader Python ecosystem.

The current implementation of the GridX portfolio code, while functional and well-tested, presents a level of complexity that may be challenging for beginners to understand. To make the codebase more accessible, especially for those new to programming or the specific technologies used, a simplification is needed.

Steps to Reproduce

1. Create an xt.input() component with a lambda function for handling events (e.g., on_input).
2. Run the application.
3. It will display TypeError related to JSON serialization of the lambda function.

The issue:

Logging in MultiagentManager currently uses print statements with a conditional variable passed as a parameter "debug" with the default value False. This is a temporary solution.

The solution:

Whenever the conditional variable "debug" is checked, simply store the current logging level in a variable, set current logging to DEBUG, log the statement, then set the logging level back to its original state. This way if a user has previously not set the logging, they do not need to manually do it in their code, they can simply pass "debug"=True. This is also helpful when you have multiple managers but you only want to debug one of them.

this almost like the doc ,but hava a error.

There are also some codes written according to the official documentation that just don't work, and I can't fix the problem.

As we optimize our applications by shifting more processing to compile-time, we've observed a significant increase in compilation times. To address this, a potential rewrite of the compiler in Rust or Mojo is proposed, aiming to improve overall performance.

FROM python:3.8-alpine
WORKDIR /app
COPY Casper.py .
COPY requirements.txt .
RUN pip install -r requirements.txt
CMD["nextpy","init","&&","nextpy","run"]

When I try to build, it shows the error: ERROR: failed to solve: dockerfile parse error on line 7: unknown instruction: CMD["nextpy","run"]

Currently, integrating certain Tailwind CSS plugins into Nextpy projects presents a significant challenge. This is primarily due to the limited customization options available within the tailwind.config.js setup. This limitation hinders the ability to fully exploit the capabilities of the Tailwind CSS ecosystem, consequently restricting design and functionality enhancements in Nextpy projects.

Specific Challenges:

• Difficulty in integrating Tailwind CSS plugins that require more complex setup than a simple require in tailwind.config.js.
• The current setup within the Nextpy framework offers limited flexibility, particularly in terms of customizing the Tailwind CSS configuration.

Suggested Solutions:

1. Template Customization:

   • Enhance the flexibility of the Jinja template (tailwind.config.js.jinja2) used in Nextpy.
   • The enhancement should aim to accommodate a variety of plugin integration scenarios, allowing for more complex plugin configurations.

2. Custom Configuration Support:

   • Enable users to provide their own tailwind.config.js file.
   • Alternatively, allow the use of a custom Jinja template for tailwind.css.
   • This would grant users greater control and versatility in terms of plugin integration and configuration.

Expected Outcome:
Implementing these solutions will significantly improve the ease of integrating diverse Tailwind CSS plugins into Nextpy projects. This enhancement is anticipated to unlock more design and functionality options, aligning Nextpy more closely with the broader Tailwind CSS ecosystem and community practices.

We could introduce @xt.method decorator in Nextpy for defining event handlers within state classes. This feature is intended to enhance code readability, standardize the declaration of methods handling state changes, and align with AI code generation practices.

Current Behavior

Currently, Nextpy requires methods within state classes to be defined directly, without specific decorators. This approach is functional but does not distinguish between regular methods and event handlers explicitly designed to modify the state.

Proposed Behavior

The introduction of the @xt.method decorator would allow developers to clearly mark methods in the state class as event handlers. This not only improves code readability but also aligns with AI code generation patterns, where such decorators are often included by default. It could also facilitate additional framework optimizations or checks.

For example:

@xt.method(ToDoState)
def delete_todo(state, todo):
    state.todos.remove(todo)

Benefits

• Improved Code Readability and Maintainability: Clearly distinguishes state-modifying methods from regular class methods.
• Alignment with AI Code Generation: Aligns with default practices of AI code generation tools, which often include method decorators in their outputs.

xt.box(


                xt.center(xt.text("YAML-2-PYTHON",
                        # margin_top="20px",
                        font_size="39px",
                        text_align="center",

                        color="violet",
                        ),),
                xt.link(
                    xt.image(src="/github.svg",
                             height="57px",
                             width="57px",
                             text_align="center",
                             align_items="center",
                             justify_content="center",
                             flex_direction="column",
                             margin_left="98em",
                             ),
                    is_external=True,
                    href="https://github.com/anirudh-hegde"
                ),
                bg="black",
                height="100%",
                align_items="center",
                justify_content="center",

        ),

It's showing

Set text and image in appropriate order

• Refactor poetry pyproject.toml file to use groups for dependencies (https://python-poetry.org/docs/managing-dependencies/)
• Remove requirements.txt once we have a working poetry setup

• Figure out the versions on which the script fails and due to what dependencies and fix those
• Update the documentation for support on latest version
• Update root pytoml file

I'm shocked to see the amount of similarity between the two frameworks:

Reflex chat UI example:

https://github.com/reflex-dev/reflex-chat/blob/main/webui/webui/webui.py

NextPy chat UI example:

https://github.com/dot-agent/nextpy/blob/main/app-examples/simple_chat/simple_chat/simple_chat.py

:3000 ERR_CONNECTION_REFUSED.
And I do not know why.

“”“
Starting Nextpy App
Compiling: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 15/15 0:00:00
Compiling takes time, but the compiled app is super fast⚡:
”“”

GitHub Issue: Refactoring the App Class in app.py for Enhanced Readability and Maintainability

Overview

The App class in app.py is central to our Nextpy application but currently handles an extensive range of functionalities, leading to complexity and potential maintainability issues. This issue aims to refactor App by effectively leveraging existing modules (admin.py, event.py, state.py) and improving code organization.

Current State

• The App class is multifaceted, combining numerous functionalities which complicates the codebase.

Objective

• Streamline the App class to efficiently utilize admin.py, event.py, and state.py.
• Reduce redundancy and enhance code clarity.

Proposal Details

1. Integration with Existing Modules:

• Thoroughly review and integrate admin.py, event.py, and state.py to offload respective functionalities from App.
• Eliminate duplicate implementations in App that are already handled by these modules.

2. Streamlining Event Handling:

• Refine event handling in App using the structured approach defined in event.py.
• Create a more intuitive interface between App and the event module for cleaner and more maintainable code.

3. State Management Refinement:

• Centralize state management responsibilities in state.py, and modify App to interact seamlessly with this module.
• Simplify and clarify the state management processes within App.

4. Admin Dashboard Integration Enhancement:

• Extract and relocate admin dashboard setup (e.g., setup_admin_dash) to a dedicated class within admin.py.
• Ensure this class handles all admin-related functionalities, providing a clean interface with App.

5. Code Cleanup and Optimization:

• Identify and refactor complex or redundant sections in App.
• Focus on enhancing readability and execution efficiency.

TODO:

• Step 1: Module Integration Review

  • Assess overlaps and interactions between App and the modules (admin.py, event.py, state.py), documenting the findings.

• Step 2: Event Handling Refinement

  • Revise App's event handling, aligning and integrating changes with event.py.

• Step 3: State Management Enhancement

  • Overhaul App's state management in coordination with modifications in state.py.

• Step 4: Admin Dashboard Integration Refinement

  • Reorganize admin dashboard functionality from App to admin.py.

• Step 5: Code Cleanup and Refactoring

  • Execute comprehensive code refinement in App, focusing on simplification and optimization.

• Step 6: Testing and Validation

  • Confirm that refactoring retains existing functionality.
  • Implement extensive testing to verify new code structures and performance.

Expected Outcomes:

• A more streamlined and readable App class.
• Reduced code redundancy and improved integration with existing modules.
• A well-organized and efficient codebase, facilitating future development and maintenance.

Additional Notes:

• Ensure backward compatibility and maintain core functionality post-refactoring.

This issue aims to significantly enhance the Nextpy framework's app.py file, focusing on structural improvements and efficient use of existing resources. The end goal is a more maintainable, clear, and efficient codebase that continues to deliver robust functionality.

The goal of this feature request is to integrate SQLSync into the Nextpy framework. SQLSync is a collaborative, offline-first wrapper around SQLite, aimed at synchronizing web application state across various users, devices, and the edge. The integration of SQLSync will enable Nextpy to efficiently manage application state in a distributed environment, enhancing its capabilities in terms of data consistency, offline functionality, and real-time collaboration.

Current State

• nextpy's run command requires a predefined directory structure for execution.

Objective

• Enable users to execute individual files with nextpy run, regardless of the directory structure, similar to tools like Streamlit .

Proposal Details

1. Command Enhancement:

• Modify nextpy run to primarily accept a file path:
  • -f or --file: Path to the target file (relative or absolute).
  • -t or --theme: Optional theme (defaults to standard if not provided).

2. Operational Logic:

• Ensure the file's existence at the given path.
• Determine the file type (e.g., .mdx, .py) and execute accordingly.
• For .mdx files, use the default MDX viewer, or apply the specified theme.
• For .py files, execute the script in an isolated or appropriate environment.
• Provide error messages and graceful exits for unsupported file types or execution errors.

3. Environment Independence:

• Eliminate dependency on a specific project structure.
• Set up the necessary minimal environment based on the file type.
• Allow environment variables or configurations to be specified via command line or external config files for flexibility.

4. Theme Integration and Default Viewer:

• Same as previously proposed.

Sample Usage:

Run a File in Any Directory:

$ nextpy run -f /path/to/file.mdx
$ nextpy run -f ./relative/path/to/script.py

With Custom Theme:

$ nextpy run -f /path/to/file.mdx -t bespoke_theme

Resultant Execution:

• Executing this command will focus on the specified file only, setting up a minimal environment as required.
• The command will be independent of the directory structure, allowing flexibility in file organization.

Advantages:

• Streamlines the process of running individual files, making it more accessible and flexible.
• Reduces the necessity for a comprehensive initial setup, facilitating quick testing and prototyping.
• Enhances the user experience, particularly beneficial for new users and in educational contexts.

Implementation Considerations:

• Robust error handling and informative messaging for user guidance.
• Extensive testing with various file locations and types to ensure reliability.
• Documentation updates to guide users on new command usage and capabilities.

Potential Directory Structure Post-Execution:

.any_directory
├── executed_file.mdx (or .py, etc.)
├── .web (if necessary for execution)
└── other_files_or_directories (unrelated to nextpy execution)

TODO

Step 1: Requirements Analysis

• Analyze the current functionality of the nextpy run command.
• Identify the limitations with respect to directory structure dependence.

Step 2: Design Command Enhancements

• Design the new command line interface to accept a file path (-f or --file) and an optional theme (-t or --theme).
• Plan how the command will handle different file types (e.g., .mdx, .py).

Step 3: Update Command Line Interface

• Modify the run command in Typer to accept the file path as a primary argument.
• Implement the logic to parse and handle the optional theme argument.

Step 4: Implement File Detection and Execution Logic

• Develop a function to validate the existence of the specified file.
• Create a function to determine the file type based on the file extension or content.
• Implement the execution logic for .mdx files, including using the default MDX viewer or the specified theme.
• Implement the execution logic for .py files, ensuring they run correctly irrespective of the directory structure.

Step 5: Environment Setup

• Establish a minimal environment setup required for the execution of the specified file.
• Ensure environment variable or configuration can be set externally if required.

Step 6: Testing and Quality Assurance

• Conduct unit testing for new functionalities.
• Perform integration testing to ensure the new command works seamlessly with existing features.
• Test the command with various file types and in different directory structures.

Step 7: Error Handling and User Feedback

• Implement robust error handling for unsupported file types, missing files, and execution errors.
• Develop user-friendly error messages and guidance for troubleshooting.

Step 8: Documentation and Examples

• Update the project documentation to include the new command usage.
• Provide example use cases and command line inputs in the documentation.