Re: [Architecture] [Dashboard] Introducing a base widget component
Hi Tanya,
Sorry for missing the required modifications in webpack.config.js in the
above mail.
Apart from the above mentioned code changes from in the React component and
the CSS stylesheet, widget author needs to do few modifications in the
webpack.config.js file as well. Those changes are as follows.
To load a CSS file as an CSS module, Webpack css-loader needs to be
configured as follows.
module.exports = {
...
module: {
loaders: [
...
{
test: /\.css$/,
loader:
'style-loader!css-loader?modules=true&localIndentName=[name]__[local]___[hash:base64:5]'
},
...
]
...
}
...
}
Here the css-loader requires two configuration properties specified.
Property Value Description
modules true This instructs the loader to load CSS as modules.
localIndentName [name]__[local]___[hash:base64:5] This defines the name of
the generated CSS classes. Since this name contains a class name along with
a hash resulting class name will be unique. Hence the styles with same
class name will not conflict anymore.
These are minimum steps needs to implement CSS module based approach. For
further references on this approach [1] provides the detailed guideline on
how to implement CSS modules, and the two sample widgets I have created can
be find at [2].
[1] https://javascriptplayground.com/blog/2016/07/css-modules-webpack-react/
[2] https://github.com/lasanthaS/dashboard-css-isolation-samples
Regards,
*Lasantha Samarakoon* | Software Engineer
WSO2, Inc.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 (71) 214 1576
Email: lasant...@wso2.com
Web:www.wso2.com
lean . enterprise . middleware
On Wed, Sep 13, 2017 at 5:59 PM, Tanya Madurapperuma wrote:
> Hi Lasantha,
>
> Could you please elaborate more on the css modules approach regarding the
> use of webpack config for name spacing the css classes.
>
> So that we can provide a sample webpack config for the widget authors to
> refer when they are writing their widgets.
>
> Thanks,
> Tanya
>
> On Wed, Sep 13, 2017 at 5:26 PM, Lasantha Samarakoon
> wrote:
>
>> Hi all,
>>
>> We looked into the Shadow DOM approach, but as Dakshika mentioned it is
>> only supported by limited number of browsers resulting we cannot consider
>> it as a feasible solution.
>>
>> There are couple of other popular approaches that we can follow in order
>> to achieve CSS isolation. *None of these approaches* can be enforced
>> from the dashboard framework level, but needs to be followed and
>> implemented by the widget authors (i.e. because each widget is an
>> separate React project with Single component). Hence what we can do is
>> provide proper guidelines to widget authors on how to write widgets.
>>
>> CSS in JS:
>>
>> In this approach the CSS styles are defined as JavaScript objects, and
>> those styles can be set to each HTML elements using the style attribute as
>> depicted in the following example. Once this is rendered the styles behave
>> similar to inline CSS styles.
>> Ex:
>>
>> ...
>>
>> const styles = {
>> button: {
>> /* Styles goes here... */
>> }
>> }
>>
>> class MyComponent extends React.Component {
>> /* ... */
>> render() {Javascript
>> return (
>>
>> );
>> }
>> /* ... */
>> }
>>
>>
>> CSS Modules:
>>
>> The other approach is using CSS modules. A CSS modules is a CSS file
>> which all class names are scoped locally (to single React component). This
>> scoping happens by suffixing each CSS class at the build time.
>>
>> So in this approach the each React component has its own CSS stylesheet
>> which needs to be imported. From the widget author's perspective, the
>> stylesheet needs to be imported and then the respective CSS classes can be
>> accessed as Javascript objects. Following examples depicts how this
>> approach looks like.
>> Ex:
>>
>> ...
>> import styles from './MyComponent.css';
>>
>> class MyComponent extends React.component {
>> /* ... */
>> render() {
>> return (
>>
>> )
>> }
>> /* ... */
>> }
>>
>>
>>
>> Appreciate your feedback on the best approach we can follow. Or if there
>> are better solutions please do suggest :)
>>
>>
>> Thanks,
>>
>> *Lasantha Samarakoon* | Software Engineer
>> WSO2, Inc.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>>
>> Mobile: +94 (71) 214 1576 <071%20214%201576>
>> Email: lasant...@wso2.com
>> Web:www.wso2.com
>>
>> lean . enterprise . middleware
>>
>> On Fri, Sep 1, 2017 at 12:21 PM, Dakshika Jayathilaka
>> wrote:
>>
>>> Hi All,
>>>
>>> AFAIK shadow DOM not supported by many browsers ATM. Can't we simply use
>>> unique ID and extend the class with ID to prevent the CSS conflicts.
>>>
>>> Regards,
>>>
>>> *Dakshika Jayathilaka*
>>> PMC Member & Committer of Apache Stratos
>>> Associate Technical Lead
>>> WSO2, Inc.
>>> lean
Re: [Architecture] [Dashboard] Introducing a base widget component
Hi Lasantha,
Could you please elaborate more on the css modules approach regarding the
use of webpack config for name spacing the css classes.
So that we can provide a sample webpack config for the widget authors to
refer when they are writing their widgets.
Thanks,
Tanya
On Wed, Sep 13, 2017 at 5:26 PM, Lasantha Samarakoon
wrote:
> Hi all,
>
> We looked into the Shadow DOM approach, but as Dakshika mentioned it is
> only supported by limited number of browsers resulting we cannot consider
> it as a feasible solution.
>
> There are couple of other popular approaches that we can follow in order
> to achieve CSS isolation. *None of these approaches* can be enforced from
> the dashboard framework level, but needs to be followed and implemented by
> the widget authors (i.e. because each widget is an separate React project
> with Single component). Hence what we can do is provide proper guidelines
> to widget authors on how to write widgets.
>
> CSS in JS:
>
> In this approach the CSS styles are defined as JavaScript objects, and
> those styles can be set to each HTML elements using the style attribute as
> depicted in the following example. Once this is rendered the styles behave
> similar to inline CSS styles.
> Ex:
>
> ...
>
> const styles = {
> button: {
> /* Styles goes here... */
> }
> }
>
> class MyComponent extends React.Component {
> /* ... */
> render() {Javascript
> return (
>
> );
> }
> /* ... */
> }
>
>
> CSS Modules:
>
> The other approach is using CSS modules. A CSS modules is a CSS file which
> all class names are scoped locally (to single React component). This
> scoping happens by suffixing each CSS class at the build time.
>
> So in this approach the each React component has its own CSS stylesheet
> which needs to be imported. From the widget author's perspective, the
> stylesheet needs to be imported and then the respective CSS classes can be
> accessed as Javascript objects. Following examples depicts how this
> approach looks like.
> Ex:
>
> ...
> import styles from './MyComponent.css';
>
> class MyComponent extends React.component {
> /* ... */
> render() {
> return (
>
> )
> }
> /* ... */
> }
>
>
>
> Appreciate your feedback on the best approach we can follow. Or if there
> are better solutions please do suggest :)
>
>
> Thanks,
>
> *Lasantha Samarakoon* | Software Engineer
> WSO2, Inc.
> #20, Palm Grove, Colombo 03, Sri Lanka
>
> Mobile: +94 (71) 214 1576 <071%20214%201576>
> Email: lasant...@wso2.com
> Web:www.wso2.com
>
> lean . enterprise . middleware
>
> On Fri, Sep 1, 2017 at 12:21 PM, Dakshika Jayathilaka
> wrote:
>
>> Hi All,
>>
>> AFAIK shadow DOM not supported by many browsers ATM. Can't we simply use
>> unique ID and extend the class with ID to prevent the CSS conflicts.
>>
>> Regards,
>>
>> *Dakshika Jayathilaka*
>> PMC Member & Committer of Apache Stratos
>> Associate Technical Lead
>> WSO2, Inc.
>> lean.enterprise.middleware
>> 0771100911 <077%20110%200911>
>>
>> On Thu, Aug 31, 2017 at 1:44 PM, Lasantha Samarakoon
>> wrote:
>>
>>> Hi all,
>>>
>>> In the new React based dashboard widget is defined as a another React
>>> component. ATM these widgets are basic React components which extends from
>>> React.Component class.
>>>
>>> But within these widgets we need to provide some extra capabilities for
>>> widget developers such as providing mechanism to inter-communicate among
>>> widgets via pub/sub, provide APIs to save widget states, etc. And also
>>> there is another issue with the current implementation i.e. the CSS styles
>>> embedded within a widget may conflict with styles applied to dashboard and
>>> other widgets (no CSS isolation).
>>>
>>> *Solution:*
>>>
>>> As a common solution for these requirements we thought of introducing a
>>> base widget class so that all the other widgets can extend from this base
>>> class instead of React.Component. By introducing this base class we can
>>> provide additional capabilities to widget developers.
>>>
>>> Ex. 1) Pub/sub
>>>
>>> For the Pub/sub implementation base widget component can expose methods
>>> and events for widgets to use (methods for publishing/subscribing to topic).
>>>
>>> Ex. 2) CSS isolation
>>>
>>> For CSS isolation we can isolate the widget content using React shadow
>>> DOM. For that we can introduce a new method called renderWidget() in the
>>> widget base class and all the widgets can define the renderWidget() instead
>>> of the React's render() method. Within the render() method of the widget
>>> class we can invoke the renderWidget() method and wrap the resultant
>>> content using React shadow DOM. High level implementation of those
>>> components will be as follows.
>>>
>>> *Widget base component:*
>>>
>>> class Widget extends React.Component {
>>> /* ... */
>>> render() {
>>> return
Re: [Architecture] [Dashboard] Introducing a base widget component
Hi all,
We looked into the Shadow DOM approach, but as Dakshika mentioned it is
only supported by limited number of browsers resulting we cannot consider
it as a feasible solution.
There are couple of other popular approaches that we can follow in order to
achieve CSS isolation. *None of these approaches* can be enforced from the
dashboard framework level, but needs to be followed and implemented by the
widget authors (i.e. because each widget is an separate React project with
Single component). Hence what we can do is provide proper guidelines to
widget authors on how to write widgets.
CSS in JS:
In this approach the CSS styles are defined as JavaScript objects, and
those styles can be set to each HTML elements using the style attribute as
depicted in the following example. Once this is rendered the styles behave
similar to inline CSS styles.
Ex:
...
const styles = {
button: {
/* Styles goes here... */
}
}
class MyComponent extends React.Component {
/* ... */
render() {Javascript
return (
);
}
/* ... */
}
CSS Modules:
The other approach is using CSS modules. A CSS modules is a CSS file which
all class names are scoped locally (to single React component). This
scoping happens by suffixing each CSS class at the build time.
So in this approach the each React component has its own CSS stylesheet
which needs to be imported. From the widget author's perspective, the
stylesheet needs to be imported and then the respective CSS classes can be
accessed as Javascript objects. Following examples depicts how this
approach looks like.
Ex:
...
import styles from './MyComponent.css';
class MyComponent extends React.component {
/* ... */
render() {
return (
)
}
/* ... */
}
Appreciate your feedback on the best approach we can follow. Or if there
are better solutions please do suggest :)
Thanks,
*Lasantha Samarakoon* | Software Engineer
WSO2, Inc.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 (71) 214 1576
Email: lasant...@wso2.com
Web:www.wso2.com
lean . enterprise . middleware
On Fri, Sep 1, 2017 at 12:21 PM, Dakshika Jayathilaka
wrote:
> Hi All,
>
> AFAIK shadow DOM not supported by many browsers ATM. Can't we simply use
> unique ID and extend the class with ID to prevent the CSS conflicts.
>
> Regards,
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Associate Technical Lead
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Thu, Aug 31, 2017 at 1:44 PM, Lasantha Samarakoon
> wrote:
>
>> Hi all,
>>
>> In the new React based dashboard widget is defined as a another React
>> component. ATM these widgets are basic React components which extends from
>> React.Component class.
>>
>> But within these widgets we need to provide some extra capabilities for
>> widget developers such as providing mechanism to inter-communicate among
>> widgets via pub/sub, provide APIs to save widget states, etc. And also
>> there is another issue with the current implementation i.e. the CSS styles
>> embedded within a widget may conflict with styles applied to dashboard and
>> other widgets (no CSS isolation).
>>
>> *Solution:*
>>
>> As a common solution for these requirements we thought of introducing a
>> base widget class so that all the other widgets can extend from this base
>> class instead of React.Component. By introducing this base class we can
>> provide additional capabilities to widget developers.
>>
>> Ex. 1) Pub/sub
>>
>> For the Pub/sub implementation base widget component can expose methods
>> and events for widgets to use (methods for publishing/subscribing to topic).
>>
>> Ex. 2) CSS isolation
>>
>> For CSS isolation we can isolate the widget content using React shadow
>> DOM. For that we can introduce a new method called renderWidget() in the
>> widget base class and all the widgets can define the renderWidget() instead
>> of the React's render() method. Within the render() method of the widget
>> class we can invoke the renderWidget() method and wrap the resultant
>> content using React shadow DOM. High level implementation of those
>> components will be as follows.
>>
>> *Widget base component:*
>>
>> class Widget extends React.Component {
>> /* ... */
>> render() {
>> return (
>>
>> renderWidget()
>>
>> );
>> }
>> /* ... */
>> }
>>
>>
>> *Widget component:*
>>
>> class MyWidget extends Widget {
>> /* ... */
>> renderWidget() {
>> return ;
>> }
>> /* ... */
>> }
>>
>>
>> Any feedback on this?
>>
>> Regards,
>>
>> *Lasantha Samarakoon* | Software Engineer
>> WSO2, Inc.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>>
>> Mobile: +94 (71) 214 1576 <+94%2071%20214%201576>
>> Email: lasant...@wso2.com
>> Web:www.wso2.com
>>
>> lean . enterprise . middleware
>>
>>
Re: [Architecture] [Dashboard] Introducing a base widget component
Hi All,
AFAIK shadow DOM not supported by many browsers ATM. Can't we simply use
unique ID and extend the class with ID to prevent the CSS conflicts.
Regards,
*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Thu, Aug 31, 2017 at 1:44 PM, Lasantha Samarakoon
wrote:
> Hi all,
>
> In the new React based dashboard widget is defined as a another React
> component. ATM these widgets are basic React components which extends from
> React.Component class.
>
> But within these widgets we need to provide some extra capabilities for
> widget developers such as providing mechanism to inter-communicate among
> widgets via pub/sub, provide APIs to save widget states, etc. And also
> there is another issue with the current implementation i.e. the CSS styles
> embedded within a widget may conflict with styles applied to dashboard and
> other widgets (no CSS isolation).
>
> *Solution:*
>
> As a common solution for these requirements we thought of introducing a
> base widget class so that all the other widgets can extend from this base
> class instead of React.Component. By introducing this base class we can
> provide additional capabilities to widget developers.
>
> Ex. 1) Pub/sub
>
> For the Pub/sub implementation base widget component can expose methods
> and events for widgets to use (methods for publishing/subscribing to topic).
>
> Ex. 2) CSS isolation
>
> For CSS isolation we can isolate the widget content using React shadow
> DOM. For that we can introduce a new method called renderWidget() in the
> widget base class and all the widgets can define the renderWidget() instead
> of the React's render() method. Within the render() method of the widget
> class we can invoke the renderWidget() method and wrap the resultant
> content using React shadow DOM. High level implementation of those
> components will be as follows.
>
> *Widget base component:*
>
> class Widget extends React.Component {
> /* ... */
> render() {
> return (
>
> renderWidget()
>
> );
> }
> /* ... */
> }
>
>
> *Widget component:*
>
> class MyWidget extends Widget {
> /* ... */
> renderWidget() {
> return ;
> }
> /* ... */
> }
>
>
> Any feedback on this?
>
> Regards,
>
> *Lasantha Samarakoon* | Software Engineer
> WSO2, Inc.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 (71) 214 1576 <+94%2071%20214%201576>
> Email: lasant...@wso2.com
> Web:www.wso2.com
>
> lean . enterprise . middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dashboard] Introducing a base widget component
+1, I think this will also help us to manage user-prefs in the future.
On Thu, Aug 31, 2017 at 1:44 PM, Lasantha Samarakoon
wrote:
> Hi all,
>
> In the new React based dashboard widget is defined as a another React
> component. ATM these widgets are basic React components which extends from
> React.Component class.
>
> But within these widgets we need to provide some extra capabilities for
> widget developers such as providing mechanism to inter-communicate among
> widgets via pub/sub, provide APIs to save widget states, etc. And also
> there is another issue with the current implementation i.e. the CSS styles
> embedded within a widget may conflict with styles applied to dashboard and
> other widgets (no CSS isolation).
>
> *Solution:*
>
> As a common solution for these requirements we thought of introducing a
> base widget class so that all the other widgets can extend from this base
> class instead of React.Component. By introducing this base class we can
> provide additional capabilities to widget developers.
>
> Ex. 1) Pub/sub
>
> For the Pub/sub implementation base widget component can expose methods
> and events for widgets to use (methods for publishing/subscribing to topic).
>
> Ex. 2) CSS isolation
>
> For CSS isolation we can isolate the widget content using React shadow
> DOM. For that we can introduce a new method called renderWidget() in the
> widget base class and all the widgets can define the renderWidget() instead
> of the React's render() method. Within the render() method of the widget
> class we can invoke the renderWidget() method and wrap the resultant
> content using React shadow DOM. High level implementation of those
> components will be as follows.
>
> *Widget base component:*
>
> class Widget extends React.Component {
> /* ... */
> render() {
> return (
>
> renderWidget()
>
> );
> }
> /* ... */
> }
>
>
> *Widget component:*
>
> class MyWidget extends Widget {
> /* ... */
> renderWidget() {
> return ;
> }
> /* ... */
> }
>
>
> Any feedback on this?
>
> Regards,
>
> *Lasantha Samarakoon* | Software Engineer
> WSO2, Inc.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 (71) 214 1576 <071%20214%201576>
> Email: lasant...@wso2.com
> Web:www.wso2.com
>
> lean . enterprise . middleware
>
--
*S. Suhothayan*
Associate Director / Architect
*WSO2 Inc. *http://wso2.com
* | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [Dashboard] Introducing a base widget component
Hi all,
In the new React based dashboard widget is defined as a another React
component. ATM these widgets are basic React components which extends from
React.Component class.
But within these widgets we need to provide some extra capabilities for
widget developers such as providing mechanism to inter-communicate among
widgets via pub/sub, provide APIs to save widget states, etc. And also
there is another issue with the current implementation i.e. the CSS styles
embedded within a widget may conflict with styles applied to dashboard and
other widgets (no CSS isolation).
*Solution:*
As a common solution for these requirements we thought of introducing a
base widget class so that all the other widgets can extend from this base
class instead of React.Component. By introducing this base class we can
provide additional capabilities to widget developers.
Ex. 1) Pub/sub
For the Pub/sub implementation base widget component can expose methods and
events for widgets to use (methods for publishing/subscribing to topic).
Ex. 2) CSS isolation
For CSS isolation we can isolate the widget content using React shadow DOM.
For that we can introduce a new method called renderWidget() in the widget
base class and all the widgets can define the renderWidget() instead of the
React's render() method. Within the render() method of the widget class we
can invoke the renderWidget() method and wrap the resultant content using
React shadow DOM. High level implementation of those components will be as
follows.
*Widget base component:*
class Widget extends React.Component {
/* ... */
render() {
return (
renderWidget()
);
}
/* ... */
}
*Widget component:*
class MyWidget extends Widget {
/* ... */
renderWidget() {
return ;
}
/* ... */
}
Any feedback on this?
Regards,
*Lasantha Samarakoon* | Software Engineer
WSO2, Inc.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 (71) 214 1576
Email: lasant...@wso2.com
Web:www.wso2.com
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
