Hi Jo, Thanks for sharing yes blog post, Yes it's true , that moving only the common code sections will solve the problem partially. So IMHO to make the code sharing more useful, we have to:
- Implement CI/CD with Travis-CI/Jenkins - For code standard checks use ESLint (IMO it's better if we could adopt an organization-wide ruleset) - Need to integrate Testing framework (We have used[1] Mocha with chai) - Documenting component APIs and usages (Could use Github WiKi) At the same time shall we move the common webpack configuration and common rule set for Javascript code style (ESLint), WDYT ? [1]: https://github.com/wso2/carbon-apimgt/tree/master/features/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main/resources/publisher/source/test Thanks ~KasunTe On Fri, Jan 5, 2018 at 12:57 AM, Joseph Fonseka <[email protected]> wrote: > Hi > > If we want to share components among projects/teams a natural approach is > to create a component library which is a common practice with organizations > working with React. But having a component library creates a another set of > problems and following medium post [1] has good explanation of them. > > +1 for creating the component library but we need to be mindful of the > problems it creates. > > From past experience if we don't have a library we will run in to lot of > copy & pasted components in products. > > Cheers > Jo > > > > [1] https://medium.com/walmartlabs/how-to-achieve-reusability-with-react- > components-81edeb7fb0e0 > > On Thu, Jan 4, 2018 at 9:49 PM, Menaka Jayawardena <[email protected]> > wrote: > >> Hi, >> >> We also faced this issue while working on the App manager component for >> the IOT Server. We had to reuse some of the components in App publisher and >> Store and this approach (creating a separate npm repository) was the >> solution we were also thinking. >> +1 for the idea. >> >> Thanks and Regards, >> Menaka >> >> On Thu, Jan 4, 2018 at 3:09 PM, Kasun Thennakoon <[email protected]> >> wrote: >> >>> Hi Manuranga, >>> >>> We could share packages within the carbon-apimgt repo with npm link as a >>> local module but if someone outside carbon-apimgt needs to get the common >>> JS files, they have to clone the whole carbon-apimgt repo and run npm link. >>> And also I have noticed that the symbolic link created by *npm link *is >>> getting removed when we run the *npm install* command later on. >>> So IMHO publishing to public npm registry would be a better solution for >>> this >>> >>> >>> Thanks >>> ~KasunTe >>> >>> On Thu, Jan 4, 2018 at 1:12 PM, Manuranga Perera <[email protected]> wrote: >>> >>>> It is also possible to link two npm projects without pushing to central >>>> repo, see https://docs.npmjs.com/cli/link >>>> >>>> >>>> On Thu, Jan 4, 2018 at 12:00 PM, Kasun Thennakoon <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> In API Manager 3.0.0 we have mainly 3 SPA applications which are >>>>> Publisher[1], Store[2], and Admin[3] apps. We have structured the SPA apps >>>>> in a way that, an App consists of 2 main elements, Data models and React >>>>> components. Data models are used to fetch data from REST APIs and >>>>> representing UI models(such as logged in user[4]). The React components >>>>> are >>>>> used to render the UI using aforementioned data models. >>>>> In the current implementation of apps, We had to repeat some of the >>>>> data models and react components in all 3 apps due to inability to share >>>>> js >>>>> modules between SPA apps. >>>>> >>>>> Because each app is located in >>>>> >>>>> *carbon-apimgt/features/apimgt/* >>>>> >>>>> >>>>> directory and if we need to refer react component in Store app from >>>>> Publisher app, we have to import it as >>>>> >>>>> >>>>>> *'../../../../org.wso2.carbon.apimgt.publisher.feature/src/main/resources/publisher/source/src/app/components/Login/Login.js'* >>>>> >>>>> >>>>> or use NPM dependency as >>>>> >>>>> >>>>>> ' >>>>>> *../../../../org.wso2.carbon.apimgt.publisher.feature/src/main/resources/publisher/source/* >>>>>> ' >>>>> >>>>> >>>>> which make it hard maintainability and share components with other >>>>> repositories/products other than "carbon-apimgt". >>>>> To overcome this issue, we could use public NPM registry to host these >>>>> sharable js modules as an NPM package and use that package as a dependency >>>>> in other places. >>>>> >>>>> When publishing common React components and Data models we could >>>>> >>>>> 1. Make a new feature named >>>>> *org.wso2.carbon.apimgt.spa.commons.feature* in *carbon-apimgt * repo >>>>> and push the npm package located in that feature into npm registry >>>>> 2. Create separate GitHub repository like *carbon-apimgt-spa-commons >>>>> *and organize all the commonly used React components and other JS >>>>> modules into that GitHub repository and publish it to npm registry >>>>> as-is. >>>>> >>>>> with the method[1] we could use the same carbon-apimgt GitHub repo and >>>>> use a subdirectory of it to hold shareable js modules(like the >>>>> @wso2-dashboards/widget[5] package). But with this approach fixing an >>>>> issue >>>>> in commons module require sending fixes to the carbon-apimgt repository. >>>>> With the [2] approach we could use separate GitHub repo associated >>>>> with npm package and setup auto release for npm package per commit similar >>>>> to what we are doing with other repositories. >>>>> Please give your suggestion and ideas on this, what would be the >>>>> better approach for publishing common components/modules to npm. >>>>> >>>>> And also, for npm package name we could use a name like >>>>> *@wso2-apimgt/commons >>>>> *with the scoping. >>>>> Please give your suggestions for a better package name as well J. >>>>> >>>>> >>>>> Thanks >>>>> ~KasunTe >>>>> >>>>> [1]: https://github.com/wso2/carbon-apimgt/tree/master/featu >>>>> res/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main >>>>> /resources/publisher >>>>> [2]: https://github.com/wso2/carbon-apimgt/tree/master/featu >>>>> res/apimgt/org.wso2.carbon.apimgt.store.feature/src/main/res >>>>> ources/store >>>>> [3]: https://github.com/wso2/carbon-apimgt/tree/master/featu >>>>> res/apimgt/org.wso2.carbon.apimgt.admin.feature/src/main/res >>>>> ources/admin >>>>> [4]: https://github.com/wso2/carbon-apimgt/blob/master/featu >>>>> res/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main >>>>> /resources/publisher/source/src/app/data/User.js >>>>> [5]: https://www.npmjs.com/package/@wso2-dashboards/widget >>>>> >>>>> -- >>>>> *Kasun Thennakoon* >>>>> Software Engineer >>>>> WSO2, Inc. >>>>> Mobile:+94 711661919 >>>>> >>>> >>>> >>>> >>>> -- >>>> With regards, >>>> *Manu*ranga Perera. >>>> >>>> phone : 071 7 70 20 50 >>>> mail : [email protected] >>>> >>> >>> >>> >>> -- >>> *Kasun Thennakoon* >>> Software Engineer >>> WSO2, Inc. >>> Mobile:+94 711661919 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Menaka Jayawardena* >> *Software Engineer - WSO2 Inc* >> *Tel : 071 350 5470* >> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena >> <https://lk.linkedin.com/in/menakajayawardena>* >> *Blog: https://menakamadushanka.wordpress.com/ >> <https://menakamadushanka.wordpress.com/>* >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kasun Thennakoon* Software Engineer WSO2, Inc. Mobile:+94 711661919
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
