Clientside extensions

How is there no clear cut method of upgrading plugins from client-resources to clientside-extensions? It seems like I have to basically throw away the entire front-end and rebuild it from scratch with zero references to real world situations present in the documentations?

How do I get the context path in CSE? How do I get inject serverside context into CSE? I can’t use PropertyProviders to inject properties anymore? I can’t use soy anymore?

I don’t even see deprecation notices for things I used to use. They’re just gone with no real replacement called out at all. This is super painful and is trial and error by fire.

Hi @steve.behnke ,

Let me answer some of the questions you have.

You can use the same approach as in any plugin. The JS API WRM.contextPath() provided by the wrm/context-pathwill do the job for you. If you are using webpack WRM plugin, this should work for you:

# my-js-file.js
import contextPath from 'wrm/context-path';

console.log(contextPath());

You can if you want. The CSE doesn’t require you to use React if you don’t want to.
There is a @atlassian/soy-loader NPM package you can use to load soy templates from the JS code e.g.:

# my-js-file.js
import myTemplate from './my-soy-template.soy';

console.log(myTemplate);

Once the soy template is loaded, you can use it to render HTML in the Modal or Panel extension point type:

# my-cse.extension.js
import { PanelExtension } from '@atlassian/clientside-extensions';
import myTemplate from './my-soy-template.soy';

/**
 * @clientside-extension
 * @extension-point bitbucket.ui.pullrequest.comment.extra
 */
export default PanelExtension.factory((extensionAPI, context) => {
    return {
        onAction: (panelAPI) => {
            panelAPI.onMount((container) => {
                container.innerHTML = myTemplate({
                    fooParam: context.pullRequest.title,
                });
            });
        },
    };

You can check the Bitbucket API changelogs. The CSE was introduced in Bitbucket in version 7.0 and the usage was extended in version 8.0:

I hope that helps.

Thanks,
Maciej Adamczak
Atlassian Developer

2 Likes

Sorry for the attitude. This is a lot more work than I expected, and doesn’t even include the backend changes.

The previous apps had been heavily written on client-resources and apparently that’s all gone now. I wasn’t actually aware it was deprecated in Bitbucket 6 because I sure wouldn’t have used it if I knew it was going to be gone in Bitbucket 7.

2 Likes

Were client-resources deprecated or did their locations just silently disappear? It’s not listed on your deprecations list.

What is the alternative to PropertyProviders? Or was this not considered API?

I can probably make due with conditions and data providers.

I’m not 100% sure, but I think the client-resources as the method of serving and providing JS/CSS/Soy content to the plugin still works. I wasn’t able to find anything in the changelog, so I don’t think those are deprecated.

The CSE is a new plugin system and did replace the web-items and web-sections. For now, the replacement was done only on some of the pages and locations in Bitbucket UI.

Sorry, but I’m not aware of what the PropertyProviders are.

So, the webpack WRM plugin can help with using DataProviders:

I’d been using this in Bitbucket 6, which doesn’t seem to list any deprecations. Client Web Item Plugin Module

Yet none of the locations in Bitbucket 7 work for the Pull Request view. I get CSE came into play here, but it’s super unclear what to do with plugin code that had been using these locations. I think you’ve answered my questions, no response required.

PropertyProviders were clearly in SPI, so that’s my bad. Not API.

Conditions have no parameters anymore I guess, since we’re loading them differently now. So that’s a weird one too. I think the answer is basically: Use a HTTP endpoint and AJAX everything.

1 Like

I was hoping these PropertyProviders had made it in, per this post on the topic: Announcement: Bitbucket Server 7.0 Early Access Program (EAP) release - #16 by rlander

It doesn’t appear they have. Is there any suggestion on how to pull in data like this, without making tons of more requests or duplicating the activities request?

I can cache things, but then I need to hit the activities endpoint and page through it, or just produce them myself in an unpaged or paged endpoint. Before, I could simply get them from the client context.