Back to Questions
1.1k
views2
comments
Constraining a Var's value?
websharperquestion

I'm implementing pagination for a datatable with the reactive layer of WebSharper. I have Vars currentPage (page number displayed) and perPage (number of rows per page). I have the data to be displayed available in a View, and the total number of rows available is also in a View.

1
2
3
4
5
6
7
8

// Vars holding state of pagination
        let paginationState = Var.Create {currentPage=1; perPage=10}
        let currentPage = paginationState.LensAuto (fun p -> p.currentPage)
        let perPage = paginationState.LensAuto (fun p -> p.perPage)
// Views on data returned by a RPC call
        let dt_countView = paginationState.View  |> View.MapAsync (fun paginationState -> async { return! Server.InstancesDataTable id (paginationState.currentPage) (paginationState.perPage) })
        let dt =  dt_countView |> View.Map (fun (data,_) -> Json.Decode<Map<string,string> array>(Json.Parse data ))
        let count =  dt_countView |> View.Map (fun (_,count) -> count )

It works well but I encounter a problem when the user changes the number of rows displayed per page. In case of such a change, the page number displayed is not changed, and it might be that we get in an inconsistent state in the sense that the currentPage doesn't exist for the new perPage value. Eg, when we have 21 rows, and display 10 rows per page, we can be on page 3 displaying 1 row. If the user then changes the perPage value to 20, currentPage with value 3 is incorrect, as only 2 pages are available.

The change of the perPage value is done through a Doc.Select, and to fix the problem, I added an onChange like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

                // function to ensure we display a valid page when the user changes
                // the number of rows displayed per page.
                let constrainCurrentPage (el:JavaScript.Dom.Element) (ev:JavaScript.Dom.Event) =
                    // access the value of a view with View.Get (fun currentValue -> ...)
                    // and do work in the function passed.
                    count
                    |> View.Get (fun c ->
                        // compute total pages with new perPage selected
                        let newTotalPages = (totalPages c (perPage.Value))
                        // if the new total pages is smaller than the current page,
                        // set the current page to the last one, else leave it as is.
                        currentPage.Set (min currentPage.Value newTotalPages))
                // FIXME: when the change of number of rows displayed per page makes that the value of currentPage
                // is after the last page, we fix the situation in constrainCurrentPage. However, this
                // way of working generates 2 RPC calls: one getting an empty list of rows when we are after the last
                // page, and one getting the list of rows after we fix the situation.
                Doc.Select [UI.Html.on.change constrainCurrentPage ] string [10; 20;30;50;100;300;500] perPage

But as the code comment explains, this generates 2 RPC calls: one when perPage value is updated by the Doc.Select one when perPage is fixed by the onChange callback.

Is there a way to avoid this duplicated RPC call? The code is available here.

.

In your current approach, the retrieval logic is bound to two separate, independent UI controls that "don't work together", and a change in either will fire the RPC call, regardless whether that change is user-initiated (selecting a dropdown) or calculated (programmatically).

Since an invalid state can only be reached when perPage is set, you could introduce an intermediate step: bind the dropdown's value to a different Var, perform the constrain logic in the control's change event as you are doing now to compute a potentially different current page number, and set that to currentPage in your model. This way, you "surround" your UI control with the extra check, instead of letting it trigger an unnecessary state change.

By on 11/16/2021 5:05 AM ()

This works perfectly and is a simple solution, thanks!

By on 11/17/2021 2:49 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper