LWC

<namespace-component-name>に置き換えられる

c デフォルト名前空間と呼ばれている。 コンポーネントを呼び出す際は、 c-my-component

モジュールで宣言されたクラス、関数、変数をインポートして利用できる

モジュールで宣言したクラス、関数、変数を他のコードで利用可能にできる

lwcはLWCのコアモジュール LightningElementは標準HTML要素のカスタムラッパー lwcモジュールからLightningElementをインポートしている

そのコンポーネントを他のコンポーネントで利用可能とするため

サポートされていない。 エクスポート可能なのはLightningElementを継承したクラスのみ

サービスコンポーネントを作成し、 変数や関数をエクスポートする。

CSSファイルと設定ファイルのみを含むモジュールを作成し、LWCのCSSファイルにそのモジュールをインポートする CSSを静的リソースにあげるのもありか？

SVGリソースをLWCと同じ名前で作成し、同じフォルダに追加する。 フォルダあたり1つまで。

ディレクティブである必要があるが、含めることができる。

できない。 アクセスするにはドット表記のみ person.firstNameみたいな

greeting currentDate1 再描画時に、ゲッターやセッターなどの式は再評価される。 プロパティは再評価されない

<template lwc:if={property}> ディレクティブを使用する elseif elseもある

HTMLのテンプレートで利用されているLWC(JavaScript)のプロパティ HTMLのテンプレートで利用されているgetterメソッドの中で使用されている LWC(JavaScript)のプロパティ ※直接HTMLテンプレートで利用してなくてもgetterを通して間接的に利用していればリアクティブとなる。

コンポーネントが再表示される。 再表示されると、すべての式が再表示される。プロパティは再評価されない (つまりgetter関数が再実行される。) renderedCallback()ライフサイクルフックが実行される。

===で変更前と変更後をチェックされる。 等価ではなく、値のIDを比較する。 よって、オブジェクト内部の変更まではチェックされない。

新しいオブジェクトを作成して再度項目に割り当てる。 @trackデコレータを利用することで内部まで項目値の変更を深く追跡させるようにする。

for:each={items} for:item="item" for:index="idx" key={item.id} {idx}:{item} <template for:each={items} for:item="item" for:index="idx"> <p key={item.id}>{idx}:{item}</p> </template>

リストの中身が変更された際、keyを利用して変更箇所を特定し再描画する。 keyは文字列か数値のみで一意である必要がある。 keyごとに要素を管理しているということ

iteratorディレクティブ 最初の要素と最後の要素の振る舞いを変えることができる。 最初の要素と最後の要素の識別が可能！

<template iterator:it={contacts}> <li key={it.value.Id}> <div if:true={it.first} class="list-first"></div> {it.value.Name}, {it.value.Title} <div if:true={it.last} class="list-last"></div> </li> </template> ※例では記載ないがindexも指定可能 この例では、スタイルを適用することで、 一番上と一番下にボーダーを表示することができる

そのコンポーネントのJavaScriptで、複数のHTMLを同フォルダからインポートし、 render()メソッドを定義し、条件に応じて返却値にHTMLを返す https://developer.salesforce.com/docs/platform/lwc/guide/create-render.html

SLDSの該当コンポーネントのVariationsセクションを確認し、 記載があるものは、標準コンポーネントでvariant属性で指定することで、そのスタイルが利用できる

SLDSのユーティリティクラスを利用する。 具体的には、上記から探したクラスをコンポーネントのクラスに適用する。 https://www.lightningdesignsystem.com/utilities/alignment/

SLDSスタイル設定フックを利用する

SLDSのStyleHooks Overviewにて該当コンポーネントのバリエーションにあう(ある場合)スタイルフックを使用する。 使用する際はホストに対して適用すれば、テンプレート内のすべてのコンポーネントにスタイルが適用される。(子コンポーネントへもスタイルが適用される　シャドウルートを貫通する) 補足として、標準コンポーネントでは CSSカスタムプロパティとして、スタイルを利用しているため、プレースホルダーとして活用している。 :host { --slds-c-button-brand-color-background: orange; --slds-c-button-brand-color-border: orange; /* Other CSS custom properties here */ }

もっとも近いSLDSブループリントをみつけて独自のコンポーネントを作成する

SLDSブループリントのタイトルの下にあるデバイスサポートの詳細を確認する (アダプティブ　レスポンシブ、デスクトップ専用)

アダプティブはデスクトップ用と非デスクトップ用のマークアップが定義されている。 レスポンシブはマークアップは1つで、画面サイズに合わせて拡大縮小される

sldsブループリントページの右上にlightningComponentボタンがある場合は対応している

ブループリントをコピーし、テンプレートへ貼り付ける ブループリントの中身で、アイコンなど基本コンポーネントに置き換え可能なものは置き換える あとはjavascriptで表示メッセージなどを制御できるようにかえる

そのコンポーネントのclassやVariant属性の値に対して{}でバインドし、JavaScriptで制御する

設計トークンを利用する —lwcプレフィックスがついている CSSカスタムプロパティで宣言する div { margin-right: var(--lwc-spacingSmall); } https://www.lightningdesignsystem.com/design-tokens/

コンパイル時に置き換えられるため、 CSSStyleDeclaration.getPropertyValue()メソッドでCSSプロパティの値を得ると、置き換えられた文字列が取得される

カスタムAuraトークンを定義し、利用する <aura:tokens> <aura:token name="myBackgroundColor" value="#f4f6f9" /> </aura:tokens> /* myLightningWebComponent.css */ color: var(--c-myBackgroundColor); --c プレフィックスで参照可能

そのコンポーネントに限定される。

子コンポーネントの内部コンポーネントに対するスタイルの適用はできないが、子コンポーネントを一つの要素としてスタイル設定はできる。

親側は　子コンポーネントのセレクタでスタイル設定する 子側は:hostセレクタでコンポーネントそのものにスタイル設定できる (:hostは親側から設定するみたいな認識)

:host(.クラス名)セレクタを利用する。 親側からセレクタで子コンポーネントにスタイル設定したのと同等 シャドウホストがセレクタにマッチする場合に適用される。 これを利用することで、子コンポーネント側からは自身に対してどのような設定が親から行われているかで、スタイル設定が可能である。 どういう時につかうかはわからん 標準コンポーネントではvariantのスタイル適用はjavascriptで制御しているし。

:host-context(セレクタ) ShadowホストがあるHTMLに対してセレクタを実行する。 ::part(セレクタ) 親側からShadowコンポーネントの要素にスタイル適用するのに使用する ネイティブShadowになれば対応するかも

salesforceが合成Shadowプロフィルを使用しているから。 将来的ににネイティブShadowになる予定らしい

Idセレクタ テンプレート表示時に、idの値がグローバル一意値に変換される場合があるため

利用可能ではない。 @apiで定義した変数は確かに利用する時属性とて扱うが、LWCエンジンでは属性名をキャメルケースに自動変換されるため、取得できない。 代替手段としてはdata-を使用し、属性セレクタで取得するなどがある

親側からHTMLで、子コンポーネントに対して変数を付与したいときに利用できる data-sub=‘aaa’ で属性設定すると、 そのオブジェクトの要素.dataset.subで取得できる。 それで子側のコンポーネントで振る舞いをかえてもいいし、 ただ単種に一意の値として、属性セレクタで取得するためのラベル付けとして利用するのもあり

スタイルフックを公開したい要素に対してカスタムプロパティを設定する。 ちなみに第二引数はデフォルト値として機能する .light { background-color: var(--light-theme-background-color, lightcyan); } 親側のコンポーネントで以下のような設定をすると、子コンポーネントに対してスタイル設定可能 :host { --light-theme-backgroud-color: honeydew;

子コンポーネントの内部要素に対してスタイル設定はできないが、 CSSカスタムプロパティを公開しておくと、親側からスタイルを適用することができる！ つまり、カスタムプロパティはShadowDomを貫通し、親側の値を継承することができる！

Salesforceでは、レンダリングされた出力に基づくスタイル設定はサポートされてない というかShadow境界を超えて基本コンポーネントに対してスタイル設定できないだけだと思う

すでに設定されているSLDSクラスに対して、上書きをしてはいけない。 将来そのクラスが変更される可能性があるため かわりとしては、設計トークンを利用したカスタムClassを付与するなどを検討する！

Classやstyle属性の場合、 その値の文字列の完全一致をセレクタで行うと、うまく取得できない場合があるため 理由としては、SalesForceが空白や予期せぬ文字を付与してしまうことがあるらしい

CSSライブラリモジュールをimportできる。 /* Example */ @import "c/cssLibrary"; cssLibrary ├──cssLibrary.css └──cssLibrary.js-meta.xml

オーナー テンプレートを所有するコンポーネント コンテナ　テンプレートの内側 親と子　そのまま

ケバブケースになる。 @api itemName に対して 親から item-name=“あああ“ で渡す

参照のみとなり、変更不可能(エラーがでる) データ変更するには浅いコピーをすればよい。

対応している 推奨はされていない

単純にオブジェクト型だとインタフェースが複雑になり開発者でオブジェクト定義を共有しないといけないから 標準HTMLでは、属性に設定できるのは、プリミティブ型のみだから。　 属性値に{オブジェクト}で渡すことができるのはLWCだけだから、想像しずらい仕様となる

子コンポーネントでメソッドに対して@apiアノテーションを付与すると、メソッドを公開することができる。 例　子側 @api play() { なんかやる } 親側は this.template.querySelector("子コンポーネント").play(); でよべる また、戻り値を設定することで、親に値を渡すこともできる 他にパラメータを設定することで、@api公開プロパティを使用せずに子に値を渡すこともできる！

公開メソッドをたたき、返却値を手に入れることができる。

@api公開メソッドの引数に値を渡せば子側で受け取ることができる また、data-属性への値設定する方法もある。

カスタム子コンポーネント側で、slotを作成する。 親側ではカスタム子コンポーネントの内部にマークアップを定義する 子側 <!-- slotDemo.html --> <template> <h1>Add content to slot</h1> <div> <slot></slot> </div> </template> 親側 <!-- slotWrapper.html --> <template> <c-slot-demo> <p>content from parent</p> </c-slot-demo> </template> slotにname属性を付与することで、親側からslot属性で割り当てるslotを選択することもできる <template> <p>First Name: <slot name="firstName">Default first name</slot></p> <p>Last Name: <slot name="lastName">Default last name</slot></p> <p>Description: <slot>Default description</slot></p> </template> <template> <c-item> <span slot={dynamicName}></span> </c-item> </template>

シャドウツリー内部に対してセレクトする場合はthis.template.querySelector() を利用する

スロットで渡されるDOM要素はシャドウツリーの一部とならならず、DOMのホスト要素に直接追加される そのため、テンプレートを使用しない、this.querySelectorで取得する。

lwc:if elseif else ディレクティブを使用し、それぞれslotタグを作成する。 従来のif:true false ディレクティブだとコンパイラが重複スロットと見なして、警告を発する

slotchangeイベント　直接の子ノードが追加、削除されると起動されるイベントである

テンプレートディレクティブを活用することで テンプレートが切り替わるごとに slotchangeイベントが呼び出されるようになる。

ShadowDomと比較して、検索範囲がコンポーネント(テンプレート)に限定されないので、別のlLightDomコンポーネントの要素やslotで渡された要素が取得されてしまう懸念がある 親側でShadow境界が作られてれば問題ない

実行コンテキストのこと つまり 今実行しているコンポーネント自身

DOM要素のクエリでwindow documentは使用しないこと。 javascriptでDomを操作しないこと(推奨) →ディレクティブをつかえ スタイル設定はおけー！

HTMLでlwc:lef属性を追加し、値を割り当てると javascriptでとれるようになる <template> <div lwc:ref="myDiv"></div> </template> export default class extends LightningElement { renderedCallback() { console.log(this.refs.myDiv); } }

とれてくる要素は参照のみの、プレーンなオブジェクトなので、そのオブジェクトの内部に対して変更や追加削除を行うとエラーがでる。 スロットやテンプレート、for:eachやiterator などのループ内の要素に対してref属性を付与することはできない。

現在表示されているものしか取得しない。 (ディレクティブによって表示されてないものは取得対象とならない)

シャドウツリーではなく、ホスト要素にコンテンツが添付される。

配布できないらしい。 管理パッケージ内で名前空間の参照はcで行うから、LightDOMでは管理パッケージ内の資産と、ローカルの資産の切り分けができないみたいな感じ？らしい

親コンポーネント側でスタイルの上書きが可能なこと サードパーティライブラリが使いやすい

static renderMode = "light" をコンポーネント内部で宣言し、 テンプレートで <template lwc:render-mode="light"> を利用する。 import { LightningElement } from "lwc"; export default class LightDomApp extends LightningElement { static renderMode = "light"; // the default is 'shadow' } <template lwc:render-mode="light"> <my-header> <p>Hello World</p> </my-header> </template>

まとめ

Shadow境界を超えてイベントを伝播させる場合は イベントのプロパティであるcomposed:trueにしておく必要がある デフォルトでなってる時もある ちなみにLightDOMでは必要なし

できない。 子側のCSSのセレクタの対象はtemplete内部に対するもの(Shadowツリー)であるため。 ホスト要素に追加されたスロット要素はCSSからはセレクトできない。

プレーンオブジェクト、配列 上記はネストされてても可能 サポートされないのは、Objectから継承するオブジェクトや、クラスインスタンス、Date Set Map など。

前の表示サイクル中にアクセスしたプロパティしか変更検知してくれないということ。 つまり、オブジェクトのプロパティを追加しても、前の表示サイクルでアクセスしてないため、検知対象とならない。 配列は問題ない。

追加しても検知してくれないので、再度割り当てる this.obj ={ ...this.obj, value: ‘あああ‘};

variant属性の値は入力apiで受け取り、 ノーマライズ(大文字→小文字変換や設定値がない場合にデフォルト値の設定)を行う。 それをもとに、文字列で各variantのスタイル定義されたクラスの値を定義し、 標準HTMLのボタンコンポーネントのクラス属性に設定する。

テンプレートはslotだけ用意している ホスト側からslotを通してボタンコンポーネントがわたってくる想定になっている ボタンコンポーネントのconnectedCallback処理で、カスタムイベントが飛ぶようになっており、 ボタングループではそれをキャッチし、ボタングループのプロパティにボタンコンポーネントを登録する(配列で管理してる) 補足として、コンストラクタでボタンから飛んでくるイベントのリスナーを登録している。 また上記の一連の処理で、 ボタン側は、自コンポーネントのプロパティにアクセスするメソッドを定義しており、ボタングループ側では、それを呼び出すことによって、orderプロパティや、ボタングループのプロパティを参照するdisconnect用のメソッドをボタン側のプロパティへに登録している。 ボタン側では、disconnectする際、そのメソッドを呼び出すことによって、ボタングループのプロパティのボタンを管理している配列から、そのボタンを削除している。

コンストラクタでやる。

this.をバインドした関数やアロー関数をイベントを介して親側に渡すことによって、親のオブジェクトから子コンポーネントを更新を行うことができ、、シームレスなやり取りができるテクニックといえる。 こういったメソッドをやり取りすることで、子からも親を更新することも可能

親のコンストラクタ実行→親のconnectedCallback→子のコンストラクタ実行→子のconnectedCallback

privateなメソッド、変数は_をつける

設定からLightningコンポーネントで該当のLWCを確認すると、連動関係がみれる

表示されない。 ただ、ネイティブshadow なら表示される

setterを定義する @apiアノテーションはgetterにだけつける

実はされてない 使うなら@apiでデコレートして入力としてサポートするようにしてほしいらしい。 ユーティリティクラス使う場合はdivとかで囲ったほうがいいかも

いいえ　順不同で渡されてくる

コンポーネントと同じフォルダにjsファイルを作成し、相対パスでインポート サービスこんぽーねんとを作成し、c/componentName形式でインポート

各jsファイルでもexportして フォルダ名と同名のjsファイルで まとめてexportする export { classSet} from ‘./classSet’; export * from ‘./banks’; アスタリスクをつかうと全部exportできる

静的リソースにアップロードして　importする import myLib from "@salesforce/resourceUrl/myLib"; platformResourceLoaderモジュールからメソッドをインポートする import { loadStyle, loadScript } from "lightning/platformResourceLoader"; インポートしてきたメソッドと実行コンテキストと静的リソースからの相対パスを指定して実行！ loadScript(this, myLib + "/myLib.js").then(() => { let result = myLib.myFunction(2, 2); });

同名のjsファイルが存在するとそちらが優先してimportされてしまうので注意 c/moduleNameとして読み込んだときに、 jsがなければ、cssを読み込むという順序で処理される

Dom操作対象のコンポーネントにたいして lwc:dom="manual"を利用する。 これを指定するとカプセル化を維持するらしい。 <template> <div lwc:dom="manual"></div> </template> これでこの要素に対してappendChildとかができる。

Lightning Lockerを使用している場合は、 ライブラリに対して制限がある Lightning Webセキュリティならないとのこと

デフォルトではできないが、 CSP信頼済みサイトに登録し、ポリシーなどの変更が必要。 JavaScriptリソースを外部から読み込むことはできない(静的リソースでやれ)