I'm working with jsps in my workplace. Pages were built using bootstrap2. Though new versions of bootstrap and other frameworks came out, I'm stuck with bootstrap2 as we have hundreds of pages using it.
How do I make the style configurable, in the sense, the configuration should give me the freedom to choose the framework, etc. So going forward I can choose what to be used for new pages
I can relate to your problem as this is the case with many "old" products in the market. They could be built with jQuery, plain js or other tools that considered "old" in today's market.
I assume you could not refactor your whole app as you are saying there hundreds of pages. Some options to consider and to set pros and cons for each with management and product teams.
First, you need to decide your technology you want to use and how.
You can use small bits of react/vue.js/other to inject into your existing pages
you can create full pages from newer technologies and slowly replace older pages in the app one by one
start a full rewrite of the app (hard to sell to management)
I did all three options in my projects but you need to decide with your own team.
Now I'll elaborate on what you can do for each of the options:
I use react so can't recommend other libraries, but this is what I used:
https://github.com/rstacruz/remount
You build react components and then you can use them as HTML snippets in your existing code.
You create another app in whatever new language you want and start building out exiting pages one by one. With each new page, you build you link the old app to them.
This is the easiest one to start but the longest one to achieve. But straightforward of what you need to do.
To make the styles configurable, you can add another stlye.css file underneath the bootstrap2 css file. In that style.css file(name it anything you want, can be bootstrap2_override.css) you can add any styles as well as override bootstrap2's framework styles.
The downside to this is that you are now adding another css file with more CSS just to override bootstrap2 styles.
Related
I am currently building a mobile app using react native. This is a parent app where parents can view marks, homework, fee details etc. We work with multiple schools and each school will need an app of their own. Only changes between these apps as of now is the splash screen and the app icon.
What can I do to keep my codebase more organized and less redundant between every app so that it will be easy to maintain, and also for new releases?
I have done a similar task before. I ported 4 different apps with unique styles from a single react native code base. You can read some related bits here.
Basically you just need to rename your app before building for ios and android.
If you need to apply different styles it is a much harder task just to explain here. However to give a hint, you need to make your app styles reusable like a theme. In my case I was using nativebase themeing. And before renaming the project I was changing the theme folder to be used for each app with a bash script. This gist might give you an idea.
For those looking for an answer,
The right way to build different apps out of the same codebase is to use android variants https://developer.android.com/studio/build/build-variants. This will allow you to sign your app with different keys for each variant. Each of these variants needs to have an appropriate folder inside the android directory, which is the place you configure splash screen, assets etc.
If you are using expo, this is not possible as you are not supposed to mess with native code. expo only supports release channels (dev, staging, prod) versions of your app.
Note: I didn't have to work with ios, so can't provide any useful links myself. But I am sure there will be something similar.
I want to use ReactJS for the front end of our new system.
The back end system (in C#) has different modules which can be toggled on/off. Each module has its own set of DLLs, meaning the product can be "shipped" without unnecessary module DLLs. "You need chat functionality? Here's the DLL, drop it in your bin folder, good to go!"
Each DLL is pretty much standalone with no dependency on an other, apart from it's main parent abstraction.
I would like to know, is it possible to create something similar in a React front end? I don't want to have hundreds of react components listed with a bunch of 'if' statements to show/hide them.
I would like each module to be responsible for its own rendering & actions. Adding a brand new feature would be as easy as 'building the extra module' (not updating the 'core' system files to tell it about the extra module).
Gah, I hope that makes sense! Could anyone point me in the right direction? Is this a fools errand? Is it achievable?
Thank you in advance.
This is more question of how to split your frontend code than react specific question. Good news is, it's certainly possible. Take a look at webapack - bundling tool often use with react. I am not sure how exactly modules and DLLs work in C#, but I imagine you have some way how to include different js bundles into them. If so, webpack will help you create these bundles.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Let's assume that I am a decent JS programmer. I can easily do React.js development. I also can write HTML and CSS to some extent. I cannot, however, build a webpage from the ground up, i.e. define the HTML structure (say in terms of React components or just plain HTML), add some CSS and get the all-shiny responsive modern-looking fancy webpage. So, I work with a designer, who uses some sort of black magic (or maybe a WYSIWYG tool, or a service like wix.com) to prototype a web page.
So, what I get is a bunch of html files, images, css styles and maybe a bit of javascript.
Now I need to convert all this into a component hierarchy of React. I'm sure I can do this, and after the job is done, I get a shiny new website, beautiful from the technological and aesthetical point of view.
However, we all know that we work in Agile environments. Later on, a designer wants me to change something. 'Add a black border' he says. And here things go out of control.
Should I do this (manually look up the style in css and add a border)? What if changes required are more complicated? Like swap a header and a footer?
Should he do this? (regenerate those source htmls/css/images again) What happens after that? Should I diff the whole website to learn what have changed and reimplement the whole component structure to reflect changes?
Are there any accepted methodologies to solve this evil circle? Maybe a tool that maps the input ugly html code to the properly done React code?
Or maybe I am totally wrong and I should learn the art of design myself?
Edit: Ok, as everybody is misundestanding the question, here is the shorter version. If the Templater changes the templates already implemented in React site, what can I do except manually diff and patch all the changes to the source css/html files?
What you're sounds a bit sketchy to me. You have to know CSS and HTML if you want to build a website, and especially maintain it. The designer probably won't be here forever for you and you would end-up in a difficult position.
The kind of flow you describe, where the designers creates all the structure and gives you the full html and css code was only working in the age of jQuery. The plug of your scripts were pretty easy and didn't required much changes, since it was decoupled from the actual html and you would use dom ids for the targeting.
How it works at Uber, but I'm sure in a lot of other companies, is that the designer is in charge of the design, but that's it, the rest is up to you. You have to make a second pass after him for the actual implementation.
Since reproduction can be pretty difficult and approximative, you can use Invision, where the designer will create the mockups, but you as a developer can get all the css properties of an element, making the integration much easier to do (dunno if wix has the same kind of feature).
If your designer updates a part of the design, it becomes straight-forward for you to know what changed and what component needs to be updated. That's one of the benefits of owning the code rather than taking one from someone else (especially if it was automatically generated).
Get the html files
Create the Router in React
Migrate the basic Layout stuff into a Layout Component
Migrate the pages content into PagesComponents
Migrate common components into your ComponentsLibrary (Navs, Buttons, etc.)
Replace the common html parts with the newly created Components
Apply logic, and so on. Refactoring, refactoring, refactoring... :)
Usually, I am asking the Templater/HTML to put their work into ReactComponents, for this I setup a simple empty React Application, with Routes definitions, and work with them, it will definitely save you a lot of time, because you can apply some logic in parallel or rethink some parts of your application, and ask for changes.
To be real efficient, they should just start by creating a pure-components library, where every component and the styles for it are isolated from the rest of the application, let them put the default values inside, and then let them use props, after the pure components are done, you can orchestrate your application with containers and logic.
The first flow you mentioned is OK, when you get only plane html and css pages from the designer/html coder.
If you are planing to create those pages with react/angular/vue whatever...
you don't need any javascript from the designer.
The steps you will need to take:
1) get html and css from designer
2) design on paper your blocks to components: header, navbar, sidebar, mainContent, footer, PostsList, Post, CommentsList, Comment, etc
3) Start building those components one by one
*Let's assume we are using react
4) make sure each component is stand alone, and extensible, for easy update in the future.
5) Make sure you have tests! Learn TDD
6) ship your app
Next cycles for updates...
1) Your designer gives you new designed pages
2) you can use the designer html and css *PARTLY and use that in your code
3) make sure you extend your components or update properly
4) tests should still work properly
Some notes before you start diving in to all that work:
learn html, css and how to build simple pages properly
you can try bootstrap it is super easy to use
learn react (if thats is what you want to use)
you will need to build your code, so you will need webpack or whatever tool.
But there is much more work ahead, so good luck it's fun! :)
This sounds like a question somebody coming from a php programming background wokring with templates would ask. React works very differently and if you wanted to be in a position where you had a base site and wanted to make changes to it going forwards you would need to have a development environment setup so that once you have made your changes, you would then 'run a build' which would produce your bundled minified javascript file, from the source code in your development environment, ready for production which you would then push to the server as you would with any site.
The reason working like this is considered the way forward is becuase it is so easy to decouple your sites logic from its aestetic. So adding a border to an element becomes as easy as adding a line of css, running your build, uploading the latest version of your app to the server and its done. As long as its written correctly to begin with you should be able to work with confidence that a visual change will only affect your site visually. Changing a classname or moving an element wont break the logic because the logic should be either in your store/actions (redux/flux store method) or local to your components code (functional component).
I have created an website/application using Angular2. The infrastructure is all set, I have routing completed, sass being processed etc.
I have sections (components) on this website that will display current web standards for our designs (buttons, forms, copy). The purpose of this site is to give our developers a copy/paste solution for markup and sass.
We will most likely create our own css library but they will still need a good visual reference of what each class does and a copy/paste solution.
I know how to develop all the standards, what I don't know how to do is have the DOM display options for the user to copy/paste the code. I could manually enter the code into or tags but this will be hard to maintain and not very clean approach. I'd like to find some solution that will utilize my code and create these tags at run time.
Googling this question leads down the road of using living style guide generators, which i don't want to use... why? I like having the functionality of controlling my own layout and scaling my standards as I see fit with our own technology.
Any ideas?
After exploring this even further I ended circling yet again on documentation tools (KSS) where I would need to rebuild my entire style guide for this functionality using markdown and or JDOCs.
Solution!
Use CodePen, its free to signup however there are some nice to have features for a monthly fee. I easily created my code here using SASS, HTML and CSS libraries. CodePen has a great EMBED feature whereas I could copy/paste html or iframe right to my styleguide.
Problem is now solved, and we have have a dynamic Web & UI Styleguide.
Hope this method helps others in my situation.
I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.
I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?
For example, we have the following departments in our app, they have distinct functionalities:
Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...
Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)
--- Pros:
Multiple programmers can work on different sub-projects in an agile
environment.
Each project is smaller and easier to be upgraded or replaced.
--- Cons:
We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.
Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.
--- Pros:
Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.
--- Cons:
Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.
Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?
First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.
Second for full disclosure I'm an engineer on the Sencha Architect team.
My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.
The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?
I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...
These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid
Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.
Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach
http://www.sencha.com/forum/showthread.php?243179
Asp.Net MVC is another good approach and might afford you some features like user auth etc...
Hopefully this helps!