You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should this all be in a single dict? Actually, a tuple, so we can unpack it in one go?
In a non-blocking route, could there be races in reading and/or changing things? Could there be races anyway?
We could also have a msg ID in the dict; incrementing this for each convert request should force a new model update too? The response object could then also include the msg ID.
What happens if in non-blocking there are several convert requests on the py side? Can we lose messages on the js side? Eg if there is an onchange in the dict, does the handler get a reference to the dict? If there are two rapid onchanges, could the first onchange handler end up reading the dict values that created the second onchange event?
The text was updated successfully, but these errors were encountered:
Currently,
base_convert
sets several model parameters separately:Should this all be in a single dict? Actually, a tuple, so we can unpack it in one go?
In a non-blocking route, could there be races in reading and/or changing things? Could there be races anyway?
We could also have a msg ID in the dict; incrementing this for each convert request should force a new model update too? The response object could then also include the msg ID.
What happens if in non-blocking there are several convert requests on the py side? Can we lose messages on the js side? Eg if there is an onchange in the dict, does the handler get a reference to the dict? If there are two rapid onchanges, could the first onchange handler end up reading the dict values that created the second onchange event?
The text was updated successfully, but these errors were encountered: