Hi,

I have a wrapped JS object (table: http://tabulator.info/) which has a function:

class TabulatorTableJS(flx.Widget):
    
    # More code

    @flx.action
    def write_cell(self, row_number, column_index, value):
        row = self.table.getRows()[row_number]
        cell = row.getCell(column_index)
        cell.setValue(value, True)

... which works great. But when calling the function/action in a loop of let's say 100 repetitions, after 40-60 repetitions, flexx throws this: [E 12:28:48 flexx.app] JS: TypeError: cell.setValue is not a function - stack trace in browser console (hit F12).

I have no idea why this is happening. It feels like some things are executed too fast on the Python side in order for the JS, but I'm just guessing here. Does anyone have an idea of what is going on or how to fix this?

Thanks, Matic

Looks like the PyWidget never gets garbage-collected. Causing all its attributes to stick around too. When these contain e.g. large datasets, this can cause severe memory leaks.

This needs some research to see what is holding a ref, and if we can solve this using e.g. a weakref. See a self-contained test-example further down.

original post

Hi @almarklein,

I have a flx.PyWidget that has flx.Widget that wraps a javascript widget as a member:

class MyWrappedWidget(flx.Widget):
  ...
  def dispose(self):
    # clean up code
    print("clean-up-completed")

  @flx.action
  def manual_dispose(self):
    # clean up code
    print("manual-clean-up-completed")

class MyPyWidget(flx.PyWidget):
  def init(self):
    with flx.VFix(flex=1) as self.frame:
      self.mywidget = MyWrappedWidget() # the wrapped widget defined above

  def dispose(self):
    # self.mywidget.dispose()
    self.mywidget.manual_dispose()
    print("MyPyWidget-clean-up")

Now when the flx.PyWidget is disposed, the manual_dispose call seems to be made, but doesn't execute, the print is never made to the command line. I also tried calling the flx.Widget's dispose method directly, but it's also doesn't execute. The wrapped flx.Widget (MyWrappedWidget) can be quite large (100's of MBs), so when old ones should be deleted and new ones created, the memory just stacks up, it doesn't get released. That's how it seems to me, don't hold me to this, I may be wrong.

Is there a way to force the child flx.Widget to get disposed?

This is a proposal for some pretty profound changes to how building apps with Flexx works. Though Flexx is still marked alpha, there are people using Flexx already, and they'd need to make some serious changes if we go this route. We thus have to think carefully whether the proposed changes are worth it.

Background

We've found Flexx to be working pretty well, even for larger applications, though the complexity of an app increases too, and we've found that newcomers to our app have trouble understanding the data-flows etc. I feel that #359 is a symptom of this, and that there is a deeper cause.

Flexx uses events. A lot. Everything is tied together using events. This is the case for both user input (mouse and key events) and property changes. The system works very nice (if I may say so myself), but a problem is that information flows all over the place, which makes it difficult to reason about the state of the application.

Flux and friends

At Facebook they had similar problems with their classic MCV approach; it scales badly because its hard to predict the state of an application based on stuff that happens in the app. Their core insight was that if information flows in one direction, an app becomes much more predictable. Here is a video that explains it very clearly (thanks @korijn) and a comic.

At Facebook they came up with a pattern (and framework) that they call Flux. The same pattern has been used in different places, in different variants, e.g. Redux and Veux. The core principal is that information flows like this:

Actions --> Dispatcher  --> One ore more stores --> Views
                /\                                    |
                 - - - - - - - - - -  Actions - - - - -

The store(s) represent the state of the application. The views listen to changes in the state and update the UI accordingly. Views (and other parts of an app) can create actions (kind of events) that are handled by the store and eventually give rise to changes in the state.

An important concept is that any actions that are dispatched (e.g. from views) are only handled after the view is done processing stuff. That's why we can legitimate saying that data flows in one direction, even though we see an arrow going to the left. Also important is that updates to the store are atomic, "commiting mutations" in Veux-terminology. The store handles actions, and then either applies mutations, or it may e.g. call out to an API, schedule some work, and eventually (asynchronously) apply mutations. Or both. This page explains it in more detail.

The state in the store is a higher-level representation of the application state; instead of having a label for which its text property represents the username, the app would have a "username" entry in the store, and a view would be responsible for showing it.

Adopting this pattern in Flexx

My initial feeling is that with this model, Flexx can look like this:

Py                             |                  JS
                               |
                        -------------------
     Server stuff <--   | Stores / models |  --> Views / widgets
         |              -------------------               |
         -- actions -->        |             <-- actions --
                               |

Where a store is a bit like our current app.Model, having properties that are synchronised between Python and JS. Properties are not set directly, but via actions that can come either from JS or Python. The views/widgets live completely in JS (they have no representation in Python).

Advantages

• Business logic is separated from UX.
• Its easier to reason about how actions change state and how state affects the UI.
• Js and Python can no longer have conflicting states, which can lead to hard-to-predict behavior.
• Due to the above points, larger applications become much easier to maintain.
• It becomes possible to set the state of an app, log actions, log the history of the state, etc. which can be awesome during developing and debugging.
• The server is only concerned with stuff that matters (app state, and server specific tasks), and is unaware of all the properties of all the widgets as is the case now. This should make the server more lean for web apps.
• If Widgets are JS-only, they are lighter, and we can instantiated them at runtime from JS. This also avoids restrictions such as discussed in #301.
• In-line callbacks for widgets are now in JS, which can help writing in a more declarative style (e.g. more like Enaml, #359). Callbacks in widgets will typically also be smaller (emit a certain action).

Disadvantages

• Ppl will have to rewrite their apps
• Simple apps become slightly more complex? Maybe not, if a store is optional. Widgets can always have internal state.

I'll make another post to give an idea of how the code would look like. This is something that I need to work on some more, and which I want to compare against current examples and apps.

It follows the same logic as setting the cookies: it is added to the object right after it has been constructed and makes sense only in the scope of web applications.

Is there any way this could be implemented as a toolkit for use with Enaml?

Flexx does have a nice declarative way of defining the structure, however the data binding aspect is separated into different handlers, which (from experience) quickly gets tedious in larger applications. Enaml nicely keeps everything contained.

Just wondering... I think flexx is pretty awesome 👍

Original title: Can flex spacing be used with SplitPanel?

If not, is there a way to set the spacing/ratio of split panels? Adding the flex parameter to widgets within a SplitPanel context does not have the desired effect.

@JohnLunzer wrote in #302:

I understand that Flexx is in part an attempt to bridge Python and Javascript. I understand also that the GUI elements of Flexx originate from the phosphor JS package. If I could draw an analogy. The PyQt package makes little if any demands on the user to understand C++ (the native language of Qt).

Do you have any goals of providing that same level of abstraction to Flexx in the future? I realize the implications of that could affect the "bridge" aspect of Flexx. With careful design I believe the UI component of Flexx could have an API which made no demands on the user to have knowledge of JS/HTML/CSS. I'm not saying that having knowledge of those languages is a bad thing, but along with the "bridge" component Flexx touts "Apps are written purely in Python". Based on my short experience with Flexx I feel like while that is technically true, a more honest statement would be "Apps are written purely in Python, with some knowledge of Javascript, HTML, and CSS."

from flexx import event

class Foo1(event.HasEvents):

    @event.prop
    def bar(self, v=0):
        return v

    @event.connect('bar')
    def on_bar(self, *events):
        print('Foo1 saw bar change')

class Foo2(event.HasEvents):

    def __init__(self):
        self.x = Foo1()
        super().__init__()

    @event.connect('x.bar')
    def on_bar(self, *events):
        print('Foo2 saw bar change')

>>> f = Foo2()
Foo1 saw bar change
>>> f.x.bar = 3
Foo1 saw bar change
Foo2 saw bar change

This was initially somewhat intended. Or at least a consequence of how the initialization worked, which at the time seemed acceptable. But I just ran into this and banged my head into the wall, so I now consider it a bug.

The point is that each object sends initial events at the end of initialization. But x does that at a time when the handlers of f are not yet connected. Maybe it makes sense to have each object check all handlers and create initial events for itself when such a handler is attached to a property.

Hi, I am new to flexx and going through http://flexx.readthedocs.io for examples. Here in http://flexx.readthedocs.io/en/latest/ui/button.html has event for mouse_click (button), checked (radio/toggle button) etc. Whereas LineEdit has only one -submit(). I want to check the data when LineEdit loses focus. Is there a way to achieve this?

e.g. I want LineEdit ui to hold only interges greater than 5000

Here is a preliminary proposal of changes to make writing (complex) apps easier and make Flexx scale better. Everything is up for discussion, so don't hesitate to challenge it.

For context and discussion see #364. I am using a PR for this proposal, so that others can easily react in-line with the text. See the "files changed" section for what I think the docs for the new Model class could look like. Below I give a summary with argumentation.

Introduction

The problems that I'd like to address with this proposal:

• A) Hard to predict flow of information in general.
• B) Need rather verbose code for simpler handlers and properties.
• C) Confusion of user on how the current Model works. Py and JS is too "entangled".
• D) Flickering effect of properties (in Python) due to eventual synchronicity.
• E) Complex memory management (it was quite leaky until #380, also see #381).
• F) Its not trivial to write apps with centralized storage.
• G) No story for updating array data effectively (e.g. scientific purposes).
• H)

First off, in my view, the Elm architecture (Flux, Veux et al.) provides two main advantages/insights: having global state that can be observed/used in different parts of the application (helping with F); having a predictable flow of information, where certain user-interactions in the view can cause an "action" that starts a new flow of information (helping with A and D).

It took me a while to come up with an approach to include these ideas in Flexx, while also keeping things simple. I've considered everything from tiny changes to a complete overhaul of the event system. The latter is not what I propose, though some changes are pretty profound and not backward compatible.

Summary + argumentation

Components

• Rename Model to Component, because it takes the role of both the M and V in MVC. The new component comes in two flavors:
• The PyComponent has all its logic in Python. It is instantiated in Python and can even be associated with multiple clients (e..g. for shared data in a chat app).
• The JSComponent has all its logic in JavaScript. It can be instantiated from Python though, in which case its state can be observed and actions can be invoked.
• No more need for the nested classes.
• The flow of information starts at actions, which mutate state, upon which there are reactions. Actions and reactions are really just methods on a Component class.
• State (properties) are readonly (makes code predictable) and can only be mutated from actions.
• Widgets should be more optional; it should be easy (and not feel like a hack) to use other means to realize the view of an app, e.g. using bootstrap.
• All components have a root attribute that refers to the main application component. This can serve as a place to keep global state (a "store" in Veux/Flux terminology).

Properties (state)

• Properties can be defined on a single line (saves lines of code).
• A standard (typed) set_foo() action can be created automatically, because its so common by foo = prop(settable=int).
• Introduce a "computed property", similar to automagic reactions mentioned below.
• Introduce an array_prop to manage state in an array. Elements can be heterogeneous (list) or typed arrays (ctypes arrays in Python). Mutations can append/insert/remove items, making syncing/tracking such state very efficient.
• Perhaps introduce a dict_prop which can similarly be mutated partially.

Actions

• Calling an action runs the action async (i.e. later), unless its called from another action. This makes it that the flow of information "starts" at the action.
• Actions can be called (i.e. invoked) from both Python and JS, as long as the args can be serialized. Think of button.set_text().
• Flexx handles one action at a time, and all reactions caused by the mutations done by the action are handled before moving on to the next action.

Reactions

• Reactions are more or less what we call handlers now, using @connect(...).
• Reactions react to mutations to make the app reflect the new state.
• Reactions react to events, in most cases by invoking new actions.
• This still works: @reaction(... connection strings ...)
• We also allow just @reaction, and let Flexx figure out the dependencies automagically.
• Inline reactions: Label(text=lambda:self.username) and Button(on_mouse_click=lambda ev: self.submit()). These will greatly help reduce code.

Renaming / restructuring

• Model ->PyComponent and JSComponent.
• The events subpackage made sense since Flexx is now very event-centric. The proposed changes make it more state-centric, and the name bugs me. Perhaps I'll just move it all to flexx.app.
• Maybe spin out pyscript and webruntime, so that we can just do flexx.PyComponent?

More motivation / argumentation

Similarity and differences w.r.t. Elm/Flux/Veux/Redux

Redux adopts a very "functional" approach to dealing with state, where reducers (i.e. actions) receive the state as an input argument, and return a new state. I don't doubt that this helps predictability, but it means having to make a copy of the whole state at each transition. This breaks down if we want to do something with data. It also does not work well with the OO style that Flexx uses.

A difference with Flux/Veux is that what they call "view", we call "reactions". One reason is that our reactions will often involve invoking actions on lower level components (e.g. widgets) rather than do DOM updates directly. So the scope of our reactions is somewhat broader, but the idea is very similar.

In most of the aforementioned frameworks there is a concept of a global/centralized state object, though each framework has another means to have some kind of modularity. In Flexx each component has its own state, and its up to the user to design the relationships in a sensible way, e.g. defining a widget's state as "local state" and using a common component, or the root component as "application state".

Debugging / testing

The clear flow of information also makes is possible/easier to create fancy debugging tools. E.g. see the list of pending actions, clicking a button to process the first one, see what mutations it causes, and which reactions follow from it. Similarly, it might help with (unit) testing.

Separation of Python and JS

It's become clear to me that Flexx' power to bring Python (server side) code and JavaScript (client side) code close together is also its weakness; it is confusing for users.

My initial take (written down originally in this PR) was to allow instantiating components in JS, in which case they exist/operate only in JS. That would make it easier to write apps that clearly separate JS code from Py code (i.e. views from application logic). I now think that this is not sufficient.

By making a component either operate in JS or Python, the concerns of such a component are much more clear. The state that can still be observed from the other end, and the actions that can be invoked, provide an easy API to handle the Python-JS interactions.

A point of discussion was whether js-components could be instantiated from Python. If not, we'd need a way to somehow bind a Python and JS entry point together, which would greatly reduce the ease and number of places where JS and Python can interact. IMO the possibility to instantiate and use a js-component from Python does not break the JS/Py separation too much, since its still fully implemented in Python.

We'd need PyScript to support context managers and keyword args to allow instantiating components in JS in the same way as we do now.

array_prop

I'd like a better story to manage arrays as state, without having to resend the whole array on each change, and making it easy for a view to update its local representation without a hard reset. Thinking of WebGL in particular, but also e.g. a list view with a lot of items. On top of this, one could implement "data sources" e.g. to manage image data.

To send mutations with data in the form of typed arrays we need a way to send binary messages. To keep things in order, this must happen over the same single websocket. So we should probably use a binary protocol instead.

Proof of concept for #303

• Allows to pass arguments to tornado.HTTPServer constructor through app.create_server.
• support for HTTPS protocol

Enable SSL transport by calling :

args = {}
args['ssl_options'] = {'certfile' : 'path-to-crtfile', 'keyfile' : 'path-to-keyfile'}
app.create_server(**args)

app.serve(Example, 'Example')
app.run()

hi,

after doing some tests and creating classes of my own to try and build a saas/spa with flexx, i come to the conclusion that flexx lacks of a lot of features to archieve that for me.

here are some points:

• simple data-binding between model-field, field-field
• more form widgets (integer, number, decimal) with optional validations
• form handling (error display/handling)
• widgets for eg a toolbar, taskbar, desktop, window
• speaking of window: moveable windows with close/min/max/... functionality

in the past i worked with Qooxdoo do build rich web interfaces, but the development structure (having a javascript frontend (gui) and some server routines in a different language) drove me to flexx.

having one framework for both server and frontend is really nice and i love python :)

greetings nolan

hi,

i'm relative new to flexx, but what i tried / seen so far is really nice 👍 .

for a little project of mine, i'm trying to build a single page application or a software as a service.

currently i'm researching/testing form<->model handling/validation. is there an how-to or a guide about two-way-data-binding?

what i have seen/tried so far is relative cumbersome.

class MyForm(flx.Widget):

    data_model = flx.DictProp(
        {'no': '1', 'name': 'Test', 'desc': 'Desc', 'dyn': 'Dyn'})

    def init(self, data=None):
        super().init()

        with flx.FormLayout():
            self.form_no = flx.LineEdit(title='No.:')
            self.form_name = flx.LineEdit(title='Name:')
            self.form_desc = flx.MultiLineEdit(title='Description:')
            with flx.HBox():
                self.save_btn = flx.Button(text='Save')
            flx.Widget(flex=1)  # Add a spacer

        self.update_model(data)

    @flx.reaction('form_no.user_done')
    def update_no(self, *events):
        data = {
            'no': events[-1]['new_value']
        }
        self.update_model(data)

    @flx.action
    def update_model(self, data):
        if data is None:
            return
        self._mutate_data_model(data, 'replace', -1)

    @flx.action
    def model_to_form(self):
        self.form_no.set_text(self.data_model['no'])
        self.form_name.set_text(self.data_model['name'])
        self.form_desc.set_text(self.data_model['desc'])

    @flx.reaction('save_btn.pointer_click')
    def save_form(self, *events):
        print(repr(self.data_model))

    @flx.reaction('data_model')
    def print_model(self, *events):
        print(repr(self.data_model))
        self.model_to_form()


class MyUI(flx.Widget):

    def init(self):
        super().init()

        with flx.HBox():
            self.form = MyForm(flex=1)


class MyApp(flx.PyComponent):

    def init(self):
        super().init()

        self.ui = MyUI()


if __name__ == '__main__':
    app = flx.App(MyApp)
    app.launch('browser')
    flx.start()

having to map each field of the form to the model and back... not very user friendly.

greetings nolan

Hello,

The problem "JS: RangeError: Maximum call stack size exceeded" is often encountered in the project, which causes the project to click without continuing to respond.

Since I am not in-depth on the underlying code research, help analyze the reasons and solutions.

Thank you.

Are there any projects that use Flexx that you could list here to see Flexx in action?

Primarily, of course, I mean open source projects whose source code is listed on Github or Gitlab. But if anyone also knows of closed-source projects, it would be great if they were listed here as well.

And I mean projects of any kind, so any projects that use Flexx as a GUI/webapp framework, but are from any category.

I'd like to get a feel for how Flex has already been used, and more importantly, how different use cases have been implemented.

So if anyone is running a public project using Flexx, feel free to link it here :)

I mean projects that are not listed under "dependents" (https://github.com/flexxui/flexx/network/dependents?package_id=UGFja2FnZS01MjEyMzE2NA%3D%3D), but if there is a particularly worth seeing project that is already listed on the site, you are welcome to point it out here again.

It isn't 100% clear to me how to write a flexx app based around asyncio. I read through:

1. #373
2. #408
3. #413 Was async ever integrated directly into flexx? I couldn't find the commit :P

Hi Almarklein,

I've added a dynamic container for widgets. I'm using it for a few applications and I thought of sharing it as I see some questions regarding adding and removing widgets on the fly.

Look at the examples, it will show you what it is capable of.

Side note: The file flexx/event/_js.py was not working for me, there is some error in _clean_code_of_thread_stuff. It seem to block a lot of examples so you are probably on it. Just use the old version or the fixed one if you have one.

Have fun ;)