Bryntum Support Forums

Hello

Recently we were attempting to use primary filter functionality on one of our combo boxes to make changes to the base searching functionality for this column (https://www.bryntum.com/docs/grid/api/Core/widget/Combo#config-primaryFilter).

However we noticed that whenever we tried to use it, we weren't able to get access to the this.value property mentioned in the docs (which represents the value the user typed in).

We tried this with a very simple example of a combo column

{
        text: 'City',
        field: 'city',
        flex: 1,
        editor: {
            type: 'combo',
            primaryFilter: {
                filterBy(record) {
                    debugger;
                    console.log(this.value);
                },
            },
            items: [{ value: 'hello', text: 'HELLO' }],
        },

. We do hit the debugger here whenever a user types into the combo box - but the value remains undefined. We attempted to replicate this issue on a bryntum demo - but the exact same code in the Bryntum basic demo (https://bryntum.com/examples/grid/basic/) seemed to work - which makes us suspect it might be a platform issue.

Do you have any idea what could be going wrong here? Can you confirm whether this could just be a issue on the Lightning platform? Are we simply using the primaryFilter wrong?

Thanks!

What version are you currently using?

Hi Alex, we're on version 4.3.9 at the moment.

Thanks, Beth

I tried to build a simple grid with version 4.3.9 in SalesForce using our examples and it works pretty well to me. See attached image.

Any chance to see more context of your code? Looks like the problem in something else.

I have reproduced the problem, and it occurs because Lightning Locker is corrupting the [[BoundThis]] for filterBy. We have one LWC which defines a config object, which is passed to another LWC to delegate construction of the grid. The corruption occurs as function properties are mutated when passed between LWC component boundaries.

The result is that when the configuration object for primaryFilter is used to construct the grid, the filterBy function is no longer bound to the right this. I think this problem could be addressed by Bryntum by using Function.apply() to force the right instance.
I was however able to work around this problem by finding the primary filter from the records first store like so...

		filterBy(record) {
			const store = record.firstStore,
				primaryFilter = store.filters.find(({ id }) => id === 'primary'),
				{ value } = primaryFilter;

instead of simply...

		filterBy(record) {
			const { value } = this;

Thanks for investigation and sharing that!

Just wanting to check the status of this thread, was this acknowledged as a bug? Can we anticipate a fix?

I cannot reproduce this problem either. Which API version do you use? is LWS enabled?

We are using Salesforce apiVersion 55, and do not have LWS enabled. Note that the problem only happens because of how the components are marshalled between two LWCs, as explained in my post of April 27. The issue will not be reproducible using a single LWC configuration.

I have reproduced the problem, and it occurs because Lightning Locker is corrupting the [[BoundThis]] for filterBy. We have one LWC which defines a config object, which is passed to another LWC to delegate construction of the grid. The corruption occurs as function properties are mutated when passed between LWC component boundaries.

Could you please share some code with us? Not clear what should we implement to reproduce the problem.