Feature Request: How can we filter out certain options making them disappear from the UI? about pcf.multiswitch HOT 15 CLOSED

Your use case makes sense 😄 And I like how detailed your feature request is... I will see what I can do tomorrow. Hopefully, I can share some recording of the dev process for the benefit of the community.

from pcf.multiswitch.

@Reinhard-S I added the Static Choices parameter if you want to play with it in the Storybook

Url again: https://albanian-xrm.github.io/PCF.MultiSwitch/?path=/story/albanianxrm-s-multiswitch-related--related

Will publish the new version soon.

from pcf.multiswitch.

Hi @Reinhard-S ,
solution has been published here the same day as my last message :)
https://github.com/albanian-xrm/PCF.MultiSwitch/releases/tag/v1.0.11-fluent

Do you have any other suggestion/request or can I close this issue?
Thanks,
Betim.

from pcf.multiswitch.

Hi @BetimBeja,

thank you very much once again, I'll use your implementation as you published it.
Have a great day! :)

Kind Regards,
Reinhard

from pcf.multiswitch.

Hi @Reinhard-S ,
filtering options should be available from the Form API. Unfortunately, there is a bug that I have raised internally with Microsoft, but there has not been much progress with. See #4 This bug is related to all third-party PCF controls AFAIK.
As a temporary workaround, you can include an OOB hidden control in the form for the same field and call the Form API's on the OOB Control, it will update the PCF state accordingly.

p.s. I will try to ping Microsoft again on this.

from pcf.multiswitch.

Hi @BetimBeja, thanks for your quick reply and for this nice control! :)

Good to know, that there is an option available through form-API! Sadly, it requires a work-around.

What's your opinion on the use case above? Wouldn't it make sense to add a filter property to your control, independent on the MS-API-bug, so items could be hidden by non-developers without additional form scripting?

As described, I'd suggest two additional properties:

1. Text (Filter), accepting a comma-separated list of integers in string format (either plain or as JSON array, the content should be bindable to a option set or a multi-option set column. It also should accept a static string array (plain or as JSON) allowing to apply static filters on forms just by customizations.
2. An integer allowing to specify the amount of digits each int-element in the filter array needs to match.

I guess, this would greatly improve functionality and helps implementing requirements without user-specific code.
Thanks!

Kind Regards,
Reinhard

from pcf.multiswitch.

Hey @Reinhard-S,
can you check out this: https://albanian-xrm.github.io/PCF.MultiSwitch/?path=/story/albanianxrm-s-multiswitch-related--related and tell me if it is solving your request?
I changed some implementation detail about the number of digits each int-element needs to match. I called it Group Size where you are specifying the size $N$ the "Group" which will be equal to $10^N$.
I will do some more testing in a Model Driven App and publish the solution tomorrow.

from pcf.multiswitch.

Hello @BetimBeja,
Wow, that was quick, thank you very much! :)
I'm unfortunately blocked by lots of appointments today but will check it latest on Monday and let you know my thoughts.
Have a nice weekend!

from pcf.multiswitch.

I am trying to show how much Storybooks help in developing PCF Components. Also, help a lot with feedback from all stakeholders 😉
ex. doing tests I realized that I didn't fix the following: Clearing selected options when the parent filter excludes those options.

from pcf.multiswitch.

@Reinhard-S if the latest release is good enough for you, you can close this issue 😄

from pcf.multiswitch.

Hello @BetimBeja,

first of all I'd like to thank you for the quick implementation, it works like a charm but initially I didn't really understand why you specified 3 as the group. I was really lost, because I thought of the "group" as being defined by the related choice items currently selected. The value of 3 therefore really confused me as the group of items should in my eyes be defined by all values where the first 6 digits match.

I guess it's just a misunderstanding, nevertheless, cutting the last three digits of each number by comparing the quotient of your 10ⁿ-division is really smart! :-)

I'm not sure if my view on things is more valid than yours but may I suggest to slightly change the formula so it's really possible to assign a group-size of 6 digits instead of the item-size? How about e.g.?:

let number = 100200300;
let groupSize = 6;
let groupId = Math.round(num / Math.pow(10, Math.floor(Math.log10(num)) - n + 1));  // groupId = 100200

Regarding your comment "ex. doing tests I realized that I didn't fix the following: Clearing selected options when the parent filter excludes those options." I also got a note / question for you:

We may place two of your controls pointing to the same field in order to separate the selectable options through two dedicated tabs (one containing all infos for Marvel, the other for DC Universe) but in this case options displayed by both controls would need to persist and being merged. I found your feature "Banished Choices" really useful for this (thanks for adding it!), but in this use-case values being banished should be kept untouched in the value of the control. Maybe you could foresee a configuration switch to control if banished values should be ignored or removed from the currently selected values?

Thank you very much!

Kind Regards,
Reinhard

from pcf.multiswitch.

Hi @Reinhard-S,
I put group size as a power of 10... meaning you can have groups of 1, 10, 100, 1000... also the formula I used can work for Choices which might have values of different lengths. ex:
1, 2, 3, 100200300, 100200301. You can use a group size 1 and it will group as follows (1,2,3), (100200300,100200301).

Regarding the behavior of removing the currently selected values, I think I can exclude the logic which removes the currently selected values if those are in the banished choices 😄

from pcf.multiswitch.

Thanks for the insights - in this case I'd treat it as a documentation challenge for you. 😄
The behavior as you implemented it is fine for now, please exclude it only based at a switch you provide in the configuration options of the control.

BTW, I missed the option to add static values in the Related Choices field, could you please enable this? This would allow me to put a static filter on groups which is quite handy for other use-cases.

Finally, I really like the test platform implementation you did with storybook. Do you happen to have a blog post on how you integrate it? I spent some time cloning your repo, used npm to get all dependencies and storybook installed and tried to get the debugger working when instantiating the control through storybook. Unfortunately, I was not able to get things right and my breakpoints were not hit. Would love to get some additional insights on your dev process, do you use VS Code, full blown Visual Studio (which i have to admit that I prefer) or do you use a different kind of tool to debug your code?

Thanks,
Reinhard

from pcf.multiswitch.

I will publish a blog post soon on how to easily setup the tests with storybook. I am using VS Code as it is best suited for Front-End development in my opinion (because of different extensions).
Also, hopefully I will get to talk about this setup later this year:

I talked about a similar setup (without componentframework-mock) here: https://youtu.be/pkyS8-JrAXU

I will add the static filter also... I added banished choices as a complementary feature 😄

from pcf.multiswitch.

Great Job, Thanks! 👍

from pcf.multiswitch.