Note that there are some explanatory texts on larger screens.

plurals
  1. POBest practise for context mode at runtime in JS
    primarykey
    data
    text
    <p>I have a web application based on apache. php, js and jquery. All works fine. </p> <p>On the client side there is a small library in JS/jquery, offering some generic list handling methods. In the past I used callbacks to handle those few issues where those methods had to behave slightly different. That way I can reuse methods like list handling, dialog handling and stuff for different part of the application. However recently the number of callbacks I had to hand through when stepping into the library grew and I am trying a redesign: </p> <p>Instead of specifying all callbacks as function arguments I created a central catalog object in the library. Each module of the application registers its own variant of callbacks into that catalog upon initialization. At runtime the methods lookup the required callbacks in that catalog instead of expecting it specified in their list of arguments. This cleans up things quite a lot. </p> <p>However I have one thing I still cannot get rid of: I require a single argument (I call it context, mode might be another term) that is used by the methods to lookup the required callback in the catalog. This context has to be handed through to all methods. Certainly better than all sorts of different callbacks being specified everywhere, but I wonder if I can get rid of that last one to. But where do I specify that context, if not as method argument ? I am pretty new to JS and jquery, so I failed to find an approach for this. Apparently I don't want to use global vars, and to be frank I doubt that I can simply store a context in a single variable anyway, since because of all the event handlers and external influences methods might be called in different contexts at the same time, or at least interleaving. So I guess I need something closer to a function stack. Maybe I can simply push a context object to the stack and read that from within the layers of the library that need to know ? The object would be removed when I leave the library again. Certainly other approaches exist too. </p> <p>Here are so many experienced coders how certainly can give a newbie like a short hint, a starting point that leads to an idea, how to implement this. How is such thing 'usually' done ? </p> <hr> <p>I tried round a while, exploring the <code>arguments.callee.caller</code> hierarchy. I thought maybe I could set a prototype member inside a calling function, then, when execution steps further down I could simply traverse the call stack upwards until I find a caller holding such property and use that value as context. However I also saw the ongoing discussions that reveal two things: 1.) <code>arguments.callee</code> appears to be depreciated and 2.) it appears to be really expensive. So that is a no go. </p> <p>I also read about the Function.caller alternative (which appears <em>not</em> to be depreciated and much more efficient, however until now I failed to explore that trail...</p> <hr> <p>As written currently passing the context/mode down simply works by specifying an additional argument in the function calls. It carries a unique string that is used as a key when consulting the catalog. So something like this (not copied, but written as primitive example): </p> <pre><code>&lt;!-- callbacks --&gt; callback_inner_task_base:function(arg1,arg2){ // do something with args } callback_inner_task_spec:function(arg1,arg2){ // do something with args } &lt;!-- catalog --&gt; Catalog.Callback:function(context,slot){ // some plausibility checks... return Catalog[context][slot]; } Catalog.base.slot=callback_inner_task_base; Catalog.spec.slot=callback_inner_task_spec; &lt;!-- callee --&gt; do_something:function(arg1,arg2,context){ ... // callback as taken from the catalog Catalog.Callback(callback,'inner_task')(arg1,arg2); ... } &lt;!-- caller --&gt; init:function(...){ ... do_something('thing-1',thing-2','base'); do_something('thing-1',thing-2','spec'); ... } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload