Who is the smart person who decided that power app controls should be isolated iframe sandbox and therefore cannot interact with Dynamics 365 in general?
No seriously, what is the purpose of PowerApps Controls? If I want to extend some out of the box feature, say I don't know the SubGrid controls, I am more than likely want to take user inputs and update the system in some sort of way. Because why else would I go through the effort to make a custom component and put on the form in the first place?
I cannot fathom, other than niche use cases, where a developer would go through the hassle of developing a component solely so it can display content and not be interacted in way where the user dose not want a record to be updated by their actions or input.
What was my issue I was trying to solve you may ask?
You cannot add events to SubGrid components. Therefore, one may want to extend its functionality to be able to have event listeners. Say you want to add a drag and drop function on a SubGrid so when a user drags and drops files onto it, it uploads it to SharePoint. You cannot interact with the DOM of the SubGrid by using traditional JS on form load so the only other option is to create something custom. You would think a custom React component can handle this simple function. But no, some really smart individual(s) decided that these React components should be isolated and unable to interact with anything when used with Dynamics 365.
What a great idea. Lets let our users create React components, put them on the forms but not let them do any API requests with them.
If you are Dynamics 365 dev, stay away from this useless garbage and stick to WebResources. At least with those you can, you know, actually extend Dynamics 365 and do stuff that is interactive and actually REACTS to user inputs.
Who is the smart person who decided that power app controls should be isolated iframe sandbox and therefore cannot interact with Dynamics 365 in general?
No seriously, what is the purpose of PowerApps Controls? If I want to extend some out of the box feature, say I don't know the SubGrid controls, I am more than likely want to take user inputs and update the system in some sort of way. Because why else would I go through the effort to make a custom component and put on the form in the first place?
I cannot fathom, other than niche use cases, where a developer would go through the hassle of developing a component solely so it can display content and not be interacted in way where the user dose not want a record to be updated by their actions or input.
What was my issue I was trying to solve you may ask?
You cannot add events to SubGrid components. Therefore, one may want to extend its functionality to be able to have event listeners. Say you want to add a drag and drop function on a SubGrid so when a user drags and drops files onto it, it uploads it to SharePoint. You cannot interact with the DOM of the SubGrid by using traditional JS on form load so the only other option is to create something custom. You would think a custom React component can handle this simple function. But no, some really smart individual(s) decided that these React components should be isolated and unable to interact with anything when used with Dynamics 365.
What a great idea. Lets let our users create React components, put them on the forms but not let them do any API requests with them.
If you are Dynamics 365 dev, stay away from this useless garbage and stick to WebResources. At least with those you can, you know, actually extend Dynamics 365 and do stuff that is interactive and actually REACTS to user inputs.