Custom hooks - March 1 #75

valentijnnieman · 2018-09-05T15:30:54Z

This adds customizable hooks before and after the fetch to dash-update-component, and makes the dash-renderer a standalone class called DashRenderer that can be called with an optional object holding request_pre and request_post functions, a la #65. Here's a simple example:

app.index_string = '''
<!DOCTYPE html>
<html>
    <head>
        {%metas%}
        <title>{%title%}</title>
        {%favicon%}
        {%css%}
    </head>
    <body>
        <div>Testing custom DashRenderer</div>
        {%app_entry%}
        <footer>
            {%config%}
            {%scripts%}
            <script id="_dash-renderer" type"application/json">
                const renderer = new DashRenderer({
                    request_pre: (req) => {
                        console.log('req:', req);
                        var output = document.getElementById('output-pre')
                        if(output) {
                            output.innerHTML = 'request_pre was fired and returned: <br/>req: ' + req + '<br/><br/>';
                        }
                    },
                    request_post: (req, res) => {
                        console.log('res:', res);
                        var output = document.getElementById('output-post')
                        if(output) {
                            output.innerHTML = 'request_post was fired and returned: <br/>res: ' + JSON.stringify(res) + '<br/><br/>';
                        }
                    }
                })
            </script>
        </footer>
        <div>With request hooks</div>
    </body>
</html>
'''

app.layout = html.Div([
    dcc.Input(
        id='input',
        value='initial value'
    ),
    html.Div(
        html.Div([
            html.Div(id='output-1'),
            html.Div(id='output-pre'),
            html.Div(id='output-post')
        ])
    )
])

@app.callback(Output('output-1', 'children'), [Input('input', 'value')])
def update_output(value):
    return value

It uses the new customizable index_string to setup a custom DashRenderer instance.

This depends on dash having support for a standalone dash-renderer, so this PR should be merged along side of this one.

DashRenderer is now a class that can be called with an optional hooks argument

src/DashRenderer.js

src/actions/index.js

src/APIController.react.js

chriddyp

Looks good! Just a few small changes

valentijnnieman · 2018-10-03T18:20:43Z

@chriddyp Thanks for your detailed explanation! Had to write some logic for the case of hooks not being used, hope I got it right.

chriddyp

The storedHooks vs hooks feels a little convoluted to me and it seems like it's mostly just an artifact of our own data flow from config argument to getting something into the store.

Reading through this a second time, it seems like getting the data into the store is causing some complexity. Since this data is static (it doesn't change through the lifecycle of the app), I don't think that we really need to wire it into the store nor create our own actions.

Instead, could we just thread hooks down through to the actions? We're already threading it through the first few components (AppProvider ➡️ AppContainer ➡️ APIController), so let's just keep threading it through until we get to the place where we're firing the actions: ➡️ TreeContainer ➡️ NotifyObservers and then wire it in as arguments in the dispatch(notifyObservers()) API calls that the NotifyObservers component makes. (e.g. here:

dash-renderer/src/components/core/NotifyObservers.react.js

Line 47 in bd3c8b3

dispatch(notifyObservers({id: ownProps.id, props: newProps}));

) and then include it in the input arguments of that function: https://github.com/plotly/dash-renderer/blob/master/src/actions/index.js#L180-L187. It's a lot of threading, but I think that's OK.

If we add more config arguments in the future, then we can abstract out hooks into a config argument and pass our data down this way.

The current solution of making these dispatches (and causing rerenders) inside APIController doesn't seem like it landed quite right, due to the complexity of hooks vs storedHooks and the fact that this data is static (it's not asynchronous like the rest of the API actions in APIController).

chriddyp · 2018-10-10T19:04:36Z

Another solution might be to place it into the store when we create it, that is here:

dash-renderer/src/AppProvider.react.js

Lines 7 to 11 in bd3c8b3

    
           const store = initializeStore(); 
        
           const AppProvider = () => ( 
        
               <Provider store={store}> 
        
                   <AppContainer/>

. Perhaps store.initializationConfig = {hooks: hooks}. Or maybe there is another way to do this with the redux reducer initialization sequence. However, that seems a little less straightforward / standard than just wiring everything through.

bpostlethwaite · 2018-10-10T19:27:02Z

FWIW I agree that wiring these hooks through the code is the way to go. Another approach for "global static config" is to use React context. However unless the config is used in a lot of places (unlike this case where we need it in a small number of sites) it's better to pass it down as props.

valentijnnieman · 2018-10-10T19:51:19Z

@bpostlethwaite Yeah, isn't the context api part of React 16 though?

I'm also wondering: if I thread it all the way down, won't it fire for each component wrapped in a <NotifyObservers/> component? Will look into this more when I have a chance, @chriddyp sounds like you're right about it not having to be in the store though. Thanks!

bpostlethwaite · 2018-10-10T20:33:03Z

Context has been part of the React API for a long time - it's recently been elevated out of "don't use this" status. But still it's probably best not to use it for the fact that it can make code harder to test / reason about.

valentijnnieman · 2018-10-11T15:58:46Z

where we're firing the actions: ➡️ TreeContainer ➡️ NotifyObservers and then wire it in as arguments in the dispatch(notifyObservers()) API calls that the NotifyObservers component makes.

Won't that pass the hooks down to all components though? Feels like it shouldn't have to be passed down to each individual one, hence why I put it in the store.
What about passing the hooks to hydrateInitialOutputs and set them in the store from there, so that they're available each time updateOutput fires?

valentijnnieman · 2018-10-11T16:35:28Z

@chriddyp Actually, thinking about it again, I don't think the dispatch(setHooks) call is async at all. It's not using any sort of thunk middleware, so I believe in this case the hooks will be set before anything else happens, so the previous version (without checking if the hooks are set) should be good.

Here's a stack overflow question about it

chriddyp · 2018-10-11T16:45:51Z

Won't that pass the hooks down to all components though?

No it won't, it will only pass it down to the NotifyObservers component, which the user doesn't have access to. It won't be in the actual props of the component.

I'm also wondering: if I thread it all the way down, won't it fire for each component wrapped in a component?

I'm not sure what you mean by "fire". It won't cause any extra renders though, because it will just be integrated into the initial props of all of the parents.

so I believe in this case the hooks will be set before anything else happens

Can you verify this yourself by putting in debugger calls?

What about passing the hooks to hydrateInitialOutputs and set them in the store from there

The main thing that I'm concerned about is that the order of operations needs to be very clear. If we have this done in APIController, the dependency of setting hooks needing to be finished before updateOutput calls is implicit rather than explicit.

.circleci/config.yml

src/actions/index.js

tests/test_render.py

…king

…into custom_hooks

tests/test_render.py

src/DashRenderer.js

alexcjohnson

Fantastic @valentijnnieman - I believe we've reached the finish line! 💃

alexcjohnson · 2019-02-27T21:17:42Z

@chriddyp pretty sure all your comments from last fall have been long since addressed - can I dismiss your review?

chriddyp · 2019-02-27T21:22:30Z

can I dismiss your review?

👍 💃 !

resolved

… custom_hooks

valentijnnieman added 4 commits September 4, 2018 15:03

Made DashRenderer standalone with hooks argument

9005923

DashRenderer is now a class that can be called with an optional hooks argument

Tests for DashRenderer with custom hooks

3fd37f5

Remove console.logs

89da3a2

Add request and response parameters to hooks

7e3045e

valentijnnieman mentioned this pull request Sep 5, 2018

Standalone dash renderer (for custom hooks) - March 1 plotly/dash#367

Merged

valentijnnieman requested a review from chriddyp September 5, 2018 15:40

Use dash-0.26.4 tarball for now

4af1751

chriddyp added the sponsored label Sep 12, 2018