Tredjeparts komponenter

Tredjeparts komponenter

Det er Ăžnskelig at tredjeparter skal kunne utvikle komponenter som en tjenesteeier skal kunne bruke i sine lĂžsninger.

Hvordan utvikle 3. parts komponenter

NÄr du som en bruker Þnsker Ä utvikle tredjeparts-komponenter sÄ er det anbefalt Ä bruke rollup.js som kompilerer til cjs (CommonJS).

Eksempel pÄ et komponent som i et fiktivt git repo (basert pÄ Gitea Repo) ligger i src/components/BalloonCounter/index.js :

import React from 'react';

export class BalloonCounter extends React.Component {
	constructor(_props, _state) {
		super(_props, _state);

		this.state = {
			count: 0,
		}
	}

	handleIncrement = () => {
		let {count} = this.state;
		count += 1;
		this.setState({
			count,
		}, () => {
			this.handleSubmitData();
		});
	}

	handleDecrement = () => {
		if(this.state.count !== 0) {
			let {count} = this.state;
			count -= 1;
			this.setState({
				count,
			}, () => {
				this.handleSubmitData();
			})
		}
	}

	handleSubmitData = () => {
		this.props.onHandleDataUpdate(this.state.count);
	}
	

	render() {
		return (
			<div>
				Number of ballons you want {this.state.count}
				<button onClick={this.handleIncrement}> + </button>
				<button onClick={this.handleDecrement}> - </button>
			</div>
		);
	}
}

Viktig: Komponentens this.props.onHandleDataUpdate(...) er en funksjon som returnerer dataene komponenten har til skjema-appen, som hÄndterer lagring i datamodell.

Husk Ă„ exportere denne classen i src/components/index.js slik:

export * from './BallonCounter.js';

NÄr npm run build blir kjÞrt vil dette lage en mappe med navn dist, med en fil som heter index.js. Denne filen mÄ vÊre med i git push for at altinn.studio skal kunne hente komponentene.

Hvordan bruke 3. parts komponenter

I tjenester du Þnsker Ä bruke 3. parts komponenter mÄ det ligge en ThirdPartyComponents.json-fil. Plasseringen av denne er viktig, den mÄ ligge under [Tjeneste navn]/editions/[utgave]/Resources. Innholdet av denne filen er som fÞlger:

{
  "packages": [{
    "packageName": "[navn pÄ pakken]",
    "location": "[Link til raw format av index.js i git-repoet]"
  }]
}

Eksempel pÄ en slik json-fil finner du her.

Hvis alt ble satt opp riktig, vil pakkene med prefiksen til pakkenavnet komme opp i toolbaren pÄ venstre side av Skjema designeren. F.eks. SuperCoolPackage.SuperCoolComponent.

Alternative lĂžsninger

  • Webpack med treeshaking
    • Positivt:
      • Webpack er allerede brukt i applikasjonen
    • Negativt:
      • Slik webpack er konfigurert idag vil det bli bygget en react-applikasjonsfil med alle komponenter, dette vil kreve en separering av react-skjemadesigner og react-runtime.
        • Runtime bygget mĂ„ skje med formLayout, som vi henter i oppstarts-fasen av applikasjonen. Slik at alle kompoenter (brukte og ubrukte komponenter) blir med i bygget.
      • Bygget mĂ„ skje fra kommando-linje/scripts som kjĂžrer i filstrukturen
  • Next.js SSR (server side rendering)
    • Positivt:
      • GjĂžre initiell rendering pĂ„ server, la klienten slippe Ă„ hente data som tekstressurser, datamodell, formLayout
      • Dynamisk henting av komponenter som ikke er standard i react-applikasjonen
    • Negativt:
      • Introdusere flere tjenester og mye endring av allerede eksisterende react-kode
  • HTTP API som starter webpack-build
    • Ved Ă„ ha et api som f.eks. Express.js, som hĂ„ndterer kompilering av applikasjon (bruker allerede kompilerte filer hvis de finnes) og blir kun brukt til Ă„ fetche javascript filen som inneholder react. Eller kun bygge da tjenesteeier klikker pĂ„ “Migrer tjeneste”.
    • Positivt:
      • Dynamisk kompilering av kun nĂždvending react applikasjon og 3. parts komponenter (kan bĂ„de kompileres da tjenesten migreres, eller hver gang et en bruker starter Ă„ fylle ut et skjema (antar at fĂžrste alternativ er mest gunstig))
    • Negativt:
      • Introdusere ny tjeneste (med mindre endringer av eksisterende kode enn “Next.js SSR”-alternativet)

Ressurser