Login component rendered after login on homepage about enso

[robbykrlos]

Hmm, good point about the SelectFilter - not sure why we chose this one instead of the EnsoSelectFilter. I'll look into it.

As for the FilterState, it's a cool thing. I'll try switching to it soon.

Thanks for your detailed explanation. Since you have spent the time to write all these details, would be a pity now not to add this to the documentation. I'll try to integrate your details into https://docs.laravel-enso.com/frontend/filters.html#renderless-filterstate 👍🏼

[robbykrlos]

Coming up with new updates and investigation results:

How to simulate:

• Set your session to 1 minute ( SESSION_LIFETIME=1)
• Login.
• wait 60 seconds.
• navigate to a page that has a table with filters. The filters need to have Options as source.
• you will be redirected to login.
• login again.
• it will try to login again on your latest page. but this will show up:

We think it has to do with something that the options are triggering / messing up. Because when you click on the menu that load the table + filters , you will trigger additional API calls to these options. The responses are 401 - unauthenticated. And maybe the logic that tries to bring user back on the initial page after re-login tries to call an API option url, instead of the initial page!?

We're still looking into it.

Any suggestions are welcomed.

Thank you,

[robbykrlos]

Hi again,

We found the issue.

We have implemented filters for our tables in most cases. Our filters are based on Option sources. Filters are rendered first in our index:

<select-filter
                    name="Customer"
                    placeholder="Customer"
                    multiple
                    label="customer_name"
                    compact
                    :source="models.customers.options"
                    :customParams="customParams"
                    v-model="filters[modelCustomer].customer_id"/>

<enso-table class="box is-paddingless raises-on-hover"
                    @clicked="clicked"
                    @fetched="fetched"
                    :filters="filters"
                    :initParams="initParams"
                    :params="params">

Now, when the session is ended and we click on another menu that tries to open this filter + table page, the requests made are in this order:

initTable
options
....
options
tableData

Now, on FE, in client/node_modules/@enso-ui/auth/src/store/auth.js there's this:

setIntendedRoute: (state, value) => (state.intendedRoute = value),

Which is ok for most cases, but in our situation, the last state.intendedRoute get's overwritten by the Option api call, which basically gets the /login page set as last state.intendedRoute

This, after login forces the app the load the latest state.intendedRoute and displays the login page in the app as hompage.

LE: This happens also in default Enso code with Activity-Log menu - here you have filters that load BEFORE timeline

We have found at this moment two workarounds, and wanted to check with you too, maybe you have one better.

1. v-if our filters to be depended on main table. This forces the logout BEFORE the options are loaded, therefore, last state.intendedRoute is the correct initTable.
2. Dirty-Fix - avoid setting the state.intendedRoute in case value is login

if(value && value.name === 'login') return; //value is nulled when state.intendedRoute is used.
state.intendedRoute = value;

Thank you,

[aocneanu]

Hi Robby,

I guess both fixes are good.

1. We try to always display filters after the table is loaded. I don't know if you are aware about the FilterState component. If not, I can share a snippet.

2. We never want the inteded route to be login.

[robbykrlos]

Hi @aocneanu,

Thanks for the quick reply, that gives us some confirmation that we can proceed safely with solution 2. too. Would you like me to get a PR done for this in @enso-ui/auth?

As for point 1. we were not aware of this component. I did a quick scan and saw it used inside the CalendarFilter. Isn't this something needed for custom filters? What I understand is that this is like a helper component used in order to create custom filters using custom controls. But in our situation we use basic @enso-ui/filters - SelectFilter which we thought it integrates nicely with the table.

If FilterState would help in our situation optimize the loading of the table before the filters, in a more elegant way (not using v-if) sure, a snippet will be useful.

Thanks again for your time 👍🏼

[aocneanu]

SelectFilter is what we call a custom filter:) The table also has internal filters that can work together with custom filters.

FiterState is a renderless component that takes care of persisting the last state of the user filter's configuration in the local state. By design, it's forcing you to use v-if for filters.

(note that we intend to integrate this in CoreTable in the near future, probably after migrating to vue3)

FilterState can handle 3 objects -> filters, intervals, params.
It needs a name that it will use as the key for storing in local storage.
It also needs an apiVersion that you will change whenever you change the code, so the previous state will be discarded.

filters & intervals are managed automatically by the table, while params can be implemented together with custom filtering on the backend.

ready: false,
apiVersion: 1.0,
filters: {
    products: {
        contract_id: [],
        is_active: null,
        manufacturer_id: [],
        ..
    },
},
intervals: {
    products: {
        updated_at: {
            min: null,
            max: null,
        },
    },
    ...
},
params: {
    dateInterval: 'all',
    anythingElse: {},
    ...
},
hasFilters: false,

Once you have the objects you can use any / all of the filters from filters and bind values from these objects.

You can use the component like this:

<filter-state :api-version="apiVersion"
    name="product-filters"
    :filters="filters"
    :intervals="intervals"
    :params="params"
    @ready="ready = true"
    @state-updated="hasFilters = $event"
    ref="filterState"/>

Notice the ready event & prop. You should use it to conditionally render the filters.

The last step is tying it to the table, this way, when the table reset button is pressed, the filters will be cleared as well.
If you want you can also use the new hasFilter prop in the table that will show you a red filter icon when any filters are applied (was requested by our users..)

<enso-table class="box is-paddingless raises-on-hover"
    id="products"
    :filters="filters"
    :params="params"
    :intervals="intervals"
    :has-filters="hasFilters"
    @reset="$refs.filterState.reset()"
    ref="table">

Of course, all of the above, together with plenty of other gems, are not documented :) (yet)

[aocneanu]

You can also do the PR for auth.

Thank you.

[robbykrlos]

Will do.

[robbykrlos]

Done @ enso-ui/auth#6