A first look to the Lookup PCF

According to the docs and the announcement made in PowerApps Blogs, we can use now the Lookup.Simple PCFs: here the docs link and the Power Apps Blog. But even a project created with the latest “pac” (Microsoft.PowerApps.CLI.1.6.4) doesn’t seem to support it. As soon we use a property of type “Lookup.Simple” like this one

<property name=”sampleProperty” display-name-key=”Property_Display_Key” description-key=”Property_Desc_Key” of-type=”Lookup.Simple” usage=”bound” required=”true” />

we get an error whyle trying to build:

The fix

By coincidence I’ve worked lately with the Field Service technician service report PCF. It allows us to make a service report by providing an out of the box solution including a PCF. But since most of the time, the service report has to be changed for every customer (at least change the company logo), Microsoft provides for us the source code for the PCF-Project. Using this, we can make changes and create a new PCF. And that’s supported 🙂

Why is that important? I’ve remembered that there is already a lookup in this PCF project. I could change the code and bundle with no issues. I didn’t need to change anything in the pcf-scripts or something similar. So, of course, I had a look and found very soon the solution: create a file named featureconfig.json in the root of the “pcfproj” project.

and the content should be
{
    "pcfAllowLookup": "on"    
}

That’s it. Now we can bundle the PCFs with simple lookps. Is it supported? If not, the service report wouldn’t be supported nether. Since it’s documented in the docs, we should be safe. Also, this won’t make problems when we upgrade the npm packages.

I’m pretty sure there will be soon a new “pac cli” version, which will support this, and then we won’t need such workarrounds.

The PCF control

The data format for the Simple.Lookup properties is similar with what we are used to: an array of objects containing id, entityType and name. Even if there are a few more properties listed in the console, I think we should consider only these:

PCF Lookup configuration

To have a main property of type lookup in the PCF is pretty straight forward. Similar to other property types, we just navigate to the “Controls” tab and choose our home-made PCF from the list. But what if we have a second property of type PCF (or the lookup property is not the main/first one in the manifest)? Have a look:

That’s becoming interesting! This customizing possibility is made special for lookup PCFs. The maker is able to decide the views and the additional filtering. Also she/he can decide if the “search box” is shown.

On the form no search box is rendered. The PCF gets a DIV container, exactly like any other control, and nothing else. I suppose that these customizing possibilities are made in order to let the maker interact with the PCF. So probably the PCF will be able to get these informations in the code. We have to wait for the docs for that.

Second open of the customizing

A little starge: when we open the customizing a second time, the property shows a little different (could be a bug for now):

Lookup.Simple missing after the name of the attribute
The extended customization not showing, so we need to change the attribute and get back in order to change the views.

Lookup Property features

We still need to be patient and wait for the docs. I didn’t found anything yet. But in the console I could see a lot of methods attached directly to the property which eventually will get supported (I’m not accessing a private subproperty, so I have hopes). It’s not supported to use them for now, since we don’t know which of them will be documented, but it looks pretty promising.

content.parameteres.secondProperty.getRecentItems()

It seems more like a mix of a field PCF having access to extended configuration and dataset/navigation methods.

Conclusion

Seeing the hints of what might come, I’ve finally understood why we had to wait for the Lookup PCF that long. And it was worth it. The PCF team thought this through , designing it to be more than a simple attribute placeholder. Thank you! Really looking forward to see the docs and start using them. Until then, we can start using the lookup PCF with the basic functionality.

7 thoughts on “A first look to the Lookup PCF

Add yours

    1. I don’t modify the scripts, Betim! I have a config file (featureconfig.json) in the root of my project. Honestly, modifying the scripts is off limits to me (because is unuspported). I like a config much better; feels cleaner. In the end it could be exactly the same change, I agree. But I have this checked-in in my github repository. And in the end, I prefer what Microsoft does too.

  1. Just try lookup property, seems it has same loading issue as dataset property, the data will not came out in first several updateViews.
    So still we need to take care the loading stuff.
    That’s quite annoying when we using multiple lookup property and dataset properties, we have to setup tons of check to make sure all the properties are loaded.
    I think there should be some parameter from context to indicate all the parameters are loaded.

    1. Hi Diana,

      Have you noticed the load issue of lookup property?

      We have struggled it for days, finally gave it up to use lookup in PCF.
      For dataset property, the `loading` property works fine, when `!dataset.loading && !dataset.error` we know the dataset is loaded for sure.

      But for lookup property, it has two related properties `loading` and `isPropertyLoading`, both of them cannot fully present the load status for lookup. We tried to combine them together, but still can’t see the pattern.

      This issue is critical when PCF display early then lookup fields, e.g. PCF in first tab, lookup in second tab, default load first tab.

      1. Hi Jerry,

        I didn’t had the issue. But I must say that I never relay on the “loaded” or “loading” or similar state. I only rely on knowing that the updateView will be called a few times, and that the last time will have the right value. So I let React render each time updateView is called.

        Would you have problems to switch to a similar approach?

      2. Hi Diana,

        Thanks for taking look on my issue!

        Yeah in most scenarios we did the same as you, we just pass the value and let react to decide the render, in react we have kind of loading frame or error frame to display different component based on property value.

        But in some cases, the ‘null’ value of the property present some kind of state, in component we will render a whole different path for it, contains several async requests, sub components, effects…So we need to secure the value is correct in first load, otherwise it will be a mess from performance perspective and also terrible for user experience.

        Finally we turn to another async request inside react, but it’s really feels bad that what we need is in this form while we still need to use another call to get it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: