feat(hitsPerPage): implement getRenderState and getWidgetRenderState

[shortcuts]

The test:watch yelled at me to add the object at L798 in connectHitsPerPage-test.ts so please if you have any advices or question about the code let me know

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit ac85f2f:

Sandbox	Source
InstantSearch.js	Configuration

[Haroenv]

looks like a good start! I haven't read the tests yet, seems like they don't run for external PRs, so we need to see them manually

[Haroenv]

good job so far!

[Haroenv]

I think this function should probably stay in init for consistency with connectorState.setHitsPerPage, but I'm not sure how other connectors dealt with this yet

[eunjae-lee]

I agree. It can stay in init.

[shortcuts]

I wasn't able to keep it in init because I got a createURLFactory is not a function error due to getWidgetRenderState getting called before init, which is weird because there's no such issues with the other widgets (it looks like). Could you check my new update @eunjae-lee ? We checked with @Haroenv to see if there was an alternative but this was the only workaround that worked.

[Haroenv]

basically the problem is that in the test (similar to breadcrumb) it seems to call getWidgetRenderState before init has happened, which means it will throw, since connectorState is still empty object at that point

[eunjae-lee]

@Haroenv @shortcuts
What do you think about this approach? 3cc8e7f

getRenderState is called before init (https://github.com/algolia/instantsearch.js/blob/feat/getWidgetRenderState-hitsPerPage/src/widgets/index/index.ts#L267:L270)
So do we rely on the fact and let getWidgetRenderState to implement connectorState? Or, do we implement connectorState even before init, but instead, let it have factory-type functions to accept things like helper or state later on?

I pushed my commit to show you for discussion, so we can drop it if we decide to go for the previous implementation.

[shortcuts]

@eunjae-lee

As I'm not that familiar with the logic behind the connectorState, your approach seems cleaner if we want to update widgets later on or if we have the same issue with an other widget, and it's not that different to other widgets.

[Haroenv]

your approach is the way to go as far as I can see @eunjae-lee, thanks!