Click here to Skip to main content
15,880,891 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hi,

I'm about to embark on a very large Javascript/Typescript driven Web UI project.

There are going to be 100s of screens making up many workflows.

I'm looking for guidance on how this can be managed within a large team environment.

For instance, phase one is to create the basic component tool kit with the required boiler plate features such as multi-language, RTL and LTR support and internal CSS rules for basic items such as text boxes, check boxes, lists e.t.c.

I want this component framework to exist in isolation as it's own project. I then want to output from this project a resource to be used by the other teams in the same way you'd share .Net component library.

The next level of development will be to design each of the workflows and it's forms which again I want done in isolation from the rest of the application. I then want a similar output from these project which will be used by an integration team who will be responsible for putting together the overall application.

We will then be writing coded UI testing to test each work flow. This is also a driving factor for each project to work in isolation as this is the level at which I want to perform our first stage integration testing.

All of this is easy to do with Visual Studio for ASP.Net where the output is a compiled .Net assembly.

But I'm struggling to find a good way to do this for a pure JS project.

One proposed solutions which I'm starting to look at is React.js and JSX syntax? Any thoughts on this?

Any other approaches or patterns you can think of which would improve the maintainability and manageability of this project?
Posted

1 solution

Where I work we have the same issue. There is a 'component' framework, which is used in other web applications. By other development teams.

For creating the components you'll have several options. React is definitly one of them.
I've also looked at Polymer which allows you to create webcomponents.

For us we settled on knockout custom components. But this was mainly because our back-end choice was to use Entity Framework with an oData webapi on top. We use Breeze.js to communicate with this back-end. And Breeze has excellent support for knockout.

All the components expose a viewModel, which is used to render the component and provide 2 way data binding.


To distribute and share the components we actually just use the NuGet packaging system. With right kind of configuration it can share javascript libraries with ease.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900