►
Description
PnP Webcast around building custom property pane controls with SharePoint Framework. Demonstration on how to build custom property pane control with client-side web parts. More details from blog post at https://dev.office.com/blogs/custom-property-pane-controls-with-sharepoint-framework
A
A
welcome
everybody.
This
is
SharePoint
balancing
back
to
say
it's
a
webcast,
and
this
time
we
do
have
slightly
advanced
scenario,
because
we
want
to
talk
about
the
fact
that
after
you
started
implementing
the
shipment
framework
in
a
more
detailed
way,
how
do
you
start
promoting
code
reusability
within
your
enterprise
scenarios
or
if
you
are
an
ISV?
How
do
you
build
those
controls
which
are
then
reusable
across
multiple
different
client-side
web
parts?
B
A
Exactly
like
mentioned,
this
is
relatively
complex
topic,
and
this
is
already
an
advanced
topic
and
we
cannot
use
the
property
pane
as
the
scenario
for
building
this
reusable
controls.
But
technically
you
can
actually
build
reusable
controls
for
client-side
web
port
presentation
layer
as
well,
but
probably
just
a
nice
example
how
to
get
started
on
the
under
implementation.
Now.
B
A
We
provide
code
samples,
reusable
components,
kindness,
documentation,
x'
community
calls
with
casts
a
lot
of
a
lot
of
stuff
for
you
to
actually
take
credit
and
the
themes
are
in
shape
and
framework
shape
and
adings
for
sharepoint
online
on-premises
max
of
graph
and
office
365
api
is
in
general
AKMs.
Sharepoint
PNP
is
the
one
address
to
remember
what
let's
actually
deep
dive
under
on
today's
topic
or
the
webcast
topic
itself.
So
we
cannot
talk
about
custom
property.
Bank
controls
might
mention
these.
A
The
let's
say
the
basic
thinking
do
apply
on
the
presentation
controls
as
well,
and
we're
going
to
talk
about
that
one
after
a
while
as
well,
but
really
when
would
you
implement
a
custom
property,
Bank
controls
or
well?
Let's,
let's
concentrate
on
a
custom
property
bank
controls
as
a
first
scenario,
and
that's
really
when
you
have
a
custom
user
experience
which
you
cannot
achieve
using
the
basic
controls
which
we
provide
as
part
of
the
SharePoint
framework.
So
something
like
a
well.
We
were
just
chit-chatting
that
with
well.
A
They
want
some
kind
of
a
scenarios
where
you
need
to
pick,
for
example,
a
you
using
mapping
control
a
Bing,
Bing
or
Google
map
control
to
select
the
position
in
the
map
or
something
like
that,
and
we
want
to
implement
that
one
inside
of
the
property
pane
well
pretty
advanced
scenario,
but
I
think
in
a
valid
use
case
for
that
one.
These
are
much
more
complex
to
implement
than
just
using
the
order
to
book
stuff
and
using
the
other
box
controls
which
are
typically
sufficient.
A
So
typically,
you
can
achieve
your
business
requirements
using
just
the
basic
controls
which
are
available,
but
if
you
can't,
then
you
need
to
move
into
the
slightly
more
complex
way
of
doing
stuff
and
when
you
are
actually
using
these
custom
controls,
you
get
reusability
and
isolation
of
the
code.
Essentially,
what
we
mean
with
that
one
is
that,
then
you
can
use
these
same
controls
across
multiple
client-side
web
parts
and
that's
really
big
advantage.
So
if
you
are
looking
into
let's
say
you
are
an
ISV,
it's
you're,
building
multiple
different
clients,
our
web
parts.
A
Many
of
them
have
a
similar
kind
of
advanced
property.
Pane,
let's
say
configuration
scenario.
You
probably
want
to
have
a
one
piece
of
code
which
you
maintain,
rather
than
copy
paste
index
that
same
code
to
all
of
the
web
parts
and
that's
what
the
custom
controls
are
actually
providing
for
you,
so
really
the
reusability
of
the
code.
So
how
do
we
actually
implement
the
the
custom
controls?
A
A
Let's
say
address
if
it's
a
mapping
control
like
the
default,
whatever
settings
or
configuration
options.
Zoom
is
a
good
option.
Yes,
indeed,
indeed
so,
there's
kind
of
a
few
too
few
different
interfaces
to
consider
in
the
property
pain
control
case
you
need
to
have
like
mention
to
I,
probably
paying
custom
field
props
implemented,
and
then
you
need
to
have
that
interface
for
whatever
you
are
exposing
as
a
configurable
option
within
your
control.
B
So
actually
the
things,
for
example,
that
are
part
of
the
eye
property
pane
custom
field,
props
interface-
are
things
like
on
render
so
that
property
pane
that
would
use
the
control
that
you
build
knows
how
how
to
render
actually
can
render
your
your
control.
So
that's
nothing
that
that
you
that
you
have
to
expose
to
pretty
pain,
but
you
don't
want
to
expose
on
the
right-hand
side.
If
you
look
at
the
chart
that
we
have
that,
you
don't
want
to
the
developer,
who
would
use
the
control
within
the
web
part?
B
B
From
interphase
point
of
view,
we
split
that
in
two
so
that,
on
the
one
hand,
side
you
have
your
own
properties
that
you
want
developers
who
would
use
the
control
that
you
build
to
be
able
to
use
and
set,
and
on
the
other
hand,
you
have
to
expose
all
of
that
to
the
from
problem
property
pain,
as
well
as
the
prerequisite
I
property
patent.
Custom
field,
props
interface,
with
all
the
things
like
dispose,
render
and
all
that
that's
required
for
your
control
to
work
correctly.
Sure.
A
So
and
that's
what
we
meant
with
the
during
the
introduction
where
we
were
saying
that
we'll
start
with
the
complex
in
area
and
from
there,
we
can
actually
further,
simplify
if
you
don't
use
the
custom
control
in
the
property
pane
context,
hopefully
that
it
makes
sense
and
kind
of
a.
If,
if
you
come
from
a
more
let's
say
from
a
Windows
background,
the
custom
controls.
What
are
we
actually
really
truly
looking
here?
Is
that
if
we
go
back
into,
let's
say
Visual
Basic
5
time
frame,
you
might.
A
Ocx
control
so
say
s,
controls
were
something
which
attracted
and
chopped
down
your
windows
forms
or
even
the
simple,
even
though
in
this
case
we
talk
about
control,
we'll
really
talk
about
reusability
of
the
code
and
packaging,
the
code
as
a
reusable
piece
of
functionality
in
the
classic
addict
model
or
see
some
implementation,
you
probably
might
have
been
using
the
BMP
core
component.
That
is
reusable
code.
You
don't
actually
copy
paste
the
code
on
every
single
sample
or
your
implementation.
A
You
reuse
a
one
piece
of
code
with
this
version
in
two
independently
and
that's
really
the
benefit
out
of
creating
these
custom
controls.
You
don't
version
the
code
as
part
of
the
client-side
web
part.
You
can
version
the
code
independently
outside
of
the
web
part
as
well.
Cute
I.
Think
that
sums
up.
What
are
we?
Hopefully?
What
are
we
trying
to
show-
and
this
will
be
when
you
do
know
that
this
webcasts
are
relatively
short-
will
absolutely
concentrate
on
a
custom
control
scenarios
more
detailed
in
the
future
as
well.
A
But
this
is
the
the
scenario
what
I'll
be
looking
at
this
case,
so
we
have
a
custom
control
on
the
right
side
which
giving
us
that
cascading
drop
down
experience
to
be
fair.
The
the
user
scenario
in
this
particular
case
wouldn't
require
a
custom
control
to
be
implemented
because
we're
just
using
a
out
of
the
box
dropdown
experience
or
two
of
thought
of
the
Box
dropdowns,
and
we
do
have
a
webcast
and
a
sample
which
is
just
implementing
this
one
directly
within
the
client-side
web
part
code.
A
But
if
you
would
use
that
same
piece
of
code
in
multiple
web
parts,
why
would
you
copy
paste
the
same
code
multiple
times
to
every
single
web
part,
because
that
will
then
cost
you
a
maintenance
challenge?
If
you
need
to
modify
the
code
or
you
need
to
enhance
the
code,
you
would
have
to
go
to
all
of
the
web
parts
and
copy
paste
and
the
code
there,
rather
than
implementing
that
that's
one
control.
Now
you
just
drag
and
drop
or
or
well
you
don't
just
tracking
trophy.
A
You
use
the
control
in
in
multiple
client-side
web
part
implementations
and
probably
many
of
you
who
are
watching
the
webcast.
You
hopefully
are
aware
of
the
office
UI
fabric
controls.
Those
are
reusable
controls
because
they
say
they
are
react,
controls
or
components
which
you
can
parameter
sized
and
they
will
then
give
you
the
let's
say,
the
rendering,
the
styling
and
basic
behavior
good
example
of
the
of
the
setup.
A
So
or
let's
say
we
do
have
classic-
is
V
providers
who
are
concentrating
on
implementing
reusable
components
and
controls
in
web
development
or
in
asp.net
or
in
classic
forms
based
development.
There's
many
many
others
with
out
there
who
are
doing
this.
You
can
still
do
exact
same
stuff
with
the
with
SharePoint
client
side
order,
a
SharePoint
framework
as
well
gute
I.
Think.
We've
seen
this
active
animation
now
going
through
quite
a
few
times,
so
we
understand,
what's
actually.
A
Fairpoint
so
exact,
let's
anyway,
actually
move
into
the
demo.
So
let's
have
a
look
on
how
we
would
take
that
existing
use
case
where
we
have
to
chop
down
some
like
mentioned:
that's
not
necessarily
a
best
use
case,
but
how
we
would
implement
that
as
a
reusable
component,
so
you're
able
to
use
the
same
piece
of
code
as
a
component
cross,
multiple
client-side
web
parts.
So
let's
switch
the
wall
Dex
computer
and
let's
have
a
look
on
the
code
which
is
available
for
you
from
a
key
table
as
well.
B
Alright,
so
with
that,
you'll
have
the
chance
to
see
the
animated
gift
again.
So
here
we
are
on
an
application.
Workbench,
we
add
the
web
part
to
the
page,
and
initially
we
don't
do
anything
right.
So
now
we
want
to
go
and
to
set
the
web
part
up.
So
we
open
the
property
pane,
and
the
first
thing
that
you
will
see
is
that
we
load
the
list
of
lists
available
in
this
site.
B
So
that
is
like
which
is
here,
and
there
are
lists
now
that
we
have
lists
available,
and
originally
you
can
see
that,
because
we
didn't
pick
in
the
list
or
yeah,
there
are
no
items
right
because
we
only
know
items
after
we
selected
a
list.
So
at
this
point
the
user
can
only
select
a
list
and
cannot
select
item.
So
we
select
a
list,
and
now
we
load
the
items
from
from
this
list,
and
now
we
can
pick
the
the
the
item.
A
Like
on
that,
one
really
kind
of
aim
facing
that
situation
so
because
we
have
that
alternative
implementation
and
if
you're
just
looking
one
time
implementation
of
this
functionality
yeah.
Maybe
that's
the
better
way
to
do
that,
but
if
you
would
have
tens
of
webparts
using
the
exact
same
scenario,
you
don't
probably
want
to
call
the
best
code
and
that's
why
we
used
that's
why
you
would
actually
implement
a
custom
control.
Yes,.
B
And
also
there's
another
thing
that
the
difference
between
the
two
ways
in
which
we
have
achieved
similarly
the
same
right.
So
here
whenever
we
switch
between
the
lists,
we
don't
block
the
web
part.
We
only
block
the
controls
where,
where
we
load
the
data
right,
because
we
now
own
the
controls,
we
are
able
to
communicate
progress
within
the
pain.
We
don't
need
to
replace
a
web
part
area,
whereas
in
the
past,
where
we
used
the
building
blocks
available
to
us
out
of
the
box,
we
couldn't
control
property
pain.
B
So
the
only
way
for
us
to
to
tell
user
that
he
needed
to
wait
for
us
to
load.
The
items
was
to
do
that
in
web
part.
So
with
that
we
had
to
clear
the
web
part
shell
spinner,
there
show
show
the
message
there
and
when
the
loading
was
done
repaying
the
web
part.
Now
we
can
add
rec
all
of
that
within
the
controls
depth
that
we
have
build
that
live
in
in
pain,
yeah
right.
B
B
So,
first
of
all,
we
go
to
a
park
right
and
the
webpart
itself
doesn't
really
do
much.
Why?
Because
we
build
a
custom
property,
pain
control
that
and
that
that
that
wraps
all
of
the
code
within
the
code
itself
right,
so
we
don't
need
to
expose
all
of
the
logic
that
we
have
to
web
part.
We
contain
that
within
our
component
or
our
control
class,
and
we
do
everything
inside
there.
The
only
thing
that
we
implement
here
is
the
property.
B
B
Example,
the
event
that
triggers
whenever
drop-down
needs
to
load
the
options
from
right,
because
here
we
use
the
same
control
once
to
load
list
and
another
time
to
load
items.
Obviously
the
logic
to
do
these
two
actions
is
not
the
same
right.
So
as
the
developer,
who
built
that
control,
we
expose
an
event
to
the
developer.
Who
would
build
the
web
part
for
them
to
be
able
to
define
how
the
control
should
get
the
items
right?
B
So
we
we
do
that
here,
then
we
have
another
event
that
we
expose
that
triggers
whenever
user
would
select
an
option
in
the
list
so
again,
developer,
who
builds
the
web
part
connect
and
react
to
that
and
as
you've
seen
whenever
we
select
a
list,
we
actually
reset
the
item.
We
load
the
items
and
we
show
new
items
of
a
in
a
pay.
Whereas
when
we
select
an
item,
we
only
store
that
in
web
part.
B
So
there
are
different
things
that
we
have
to
do
based
on
the
control
and
with
the
event
that
we
expose
here
developer,
who
actually
builds
the
web
part
would
use.
The
control
can
can
do
all
that.
Another
thing
that
we
expose
is,
for
example,
property
that
it
has
selected.
So
in
our
case,
when
you
would
select
a
list,
you
would
close
in
the
the
web
part,
you
would
reload
the
page
and
you
would
set
it
up
again.
The
thing
that
you
would
want
to
see
is
the
list
that
you
have
selected
in
the
past
right.
B
B
So
let's
have
a
look
at
the
property
pane,
a
soon
drop
down
class.
How
that
is
built
so
that
class
represents
the
custom
property
paying
controlled
that
we
have
built
and
to
work
properly.
It
has
to
implement
the
I
property
pain-filled
interface.
That
requires
a
type
of
properties
used
by
the
control
to
be
passed
as
well.
B
In
our
case,
as
the
I
property
pane,
Aysen
rubbed
on
props
interface,
which
has
things
like
label
load
option
on
property
change,
selected
key
disabled,
and
these
are
exactly
the
properties
that
we
expose
here
in
the
web
parts
to
the
developer.
Who
would
use
the
control
to
build
the
web
part
to
actually
set
right
so
anything
that
you
want
developer?
Who
will
use
a
control
to
be
able
to
set
you
have
to
expose
now?
There
is
one
interesting
part.
B
This
interface
requires
you
to
pass
the
the
tide
and
we
use
that
type
as
interface
for
its
properties,
but
actually
for
this
type.
It
requires
few
more
things
as
well.
One
of
the
things
is,
if
we
zoom
into
that,
because
for
that
we
have
implemented
and
our
interface,
and
you
will
see
why.
So
here
we
extend
or
actually
we
combine,
the
I
property,
paying
a
sink
down.
B
Probes
interface,
that
we
have
built
ourselves
with
the
out-of-the-box
I,
properly
paint,
custom
field,
props
interface,
which
has
things
like
on,
render
on
disposed
and
context,
and
if
you
go
all
the
way
back
to
the
class
here,
which
is
here
the
property
pain
in
order
to
be
able
to
render
our
control
has
to
have
the
render
event
right.
So
that
comes
from
the
out-of-the-box
I
property
pain,
custom
field,
props
interface
that
we
implement,
but
but
but
but
we
don't
want
to
expose
the
on
render
event
or
the
method
to
the
the
developer.
B
Who
would
use
the
web
part
or
use
the
control
within
the
web
part
right,
because
imagine
that
if
we
did,
if
we
implement
it
exactly
the
same
universe
here,
if
you
would
go
back
to
web
part
such
as
only
here,
you
would
have
to
implement
the
own
render
right
and
you
would
have
to,
or
you
would
basically
override
the
way
we
render
the
control.
So
we
don't
want
to
do
you
do
that
so
with
that
we
actually
hide
the
internal
prerequisites.
B
B
We
have
I
property
pain,
async,
Dom
props,
with
which
are
all
the
things
that
that
you
own
developers
who
would
use
the
web
to
be
able
to
set
versus
the
things
that
the
web
part,
or
that
the
control
has
to
have
in
order
for
it
to
work
correctly,
which
is
here,
which
is
actually
a
combination
of
everything
that
you
want
developers
to
be
able
to
set
with
everything
else.
That's
required
by
the
the.
B
At
that
point,
basically,
what
what
what
we
do
is
that
we
trigger
events.
We
build
that
with
in
react,
so
we
created,
we
created,
react
component
that
does
the
rendering
right
so
here
we
have
react
code
that
has
its
own
state
properties
and
in
that
way
it
works
very
similar.
At
this
point,
it
works
similar
to
how
you
would
build
a
web
part
in
react
right.
It's
exactly
the
same.
You
work
with
this
state,
you
pass
properties
and
it
gives
it
back,
and
at
that
point
we
can
trigger
events.
A
This
way
you
have
a
carnival
separation
of
concerns
as
well,
so
the
web
part
is
the
one
which
is
responsible
of
loading
the
stuff,
but
in
the
control
is
the
one
which
is
responsible
of
the
behavioral
on
between
the
different
data.
What
has
been
loaded
technically?
You
have
actually
load
the
stuff,
obviously
in
the
control
as
well,
but
then
that
would
reduce
the
reusability
of
the
control.
It's
a
matter
of
an
architect.
It's
an
architectural
decision,
whatever.
B
A
Absolutely
well,
there
is
multiple
Sena,
multiple
Carnivale,
but
that's
no
doubt
the
right
way
of
doing
stuff.
So
technically
you
could
do
that.
It's
not
feasible
to
do,
and
maybe
there's
a
certain
scenarios
where
you
want
to
build
this
more,
let's
say
dedicated
controls
which
are
then
used
by
clients
at
webparts.
Who
knows
both
options
are
valid,
but
no
doubt
this
way
the
control
itself
concentrates
on
the
UX
and
doesn't
control
concentrate
on
where
the
data
is
actually
coming.
So
really
good
approach,
yeah.
A
Good,
let's
switch
back
on
the
presentation
and
close
the
webcast,
Thank
You
Walden
couch
cute
demo.
Hopefully
you
were
able
to
understand
the
value
of
that
one.
It
is
slightly
complex,
like
we
will
be
mentioning
true
true
the
webcast
quite
a
few
times,
and
this
is
an
advanced
scenario
if
you're
looking
into
just
a
I'm
going
to
implement
my
first
client-side
web
part
using
SharePoint
framework.