6

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?

Hedin
  • 630
  • 3
  • 8
  • 19
  • You should do this. This is the nature of web development, if there is a css change, then change the css. If you need to swap the header and footer, then move the components. There is no 'evil circle' to avoid, if a change comes in then make it. Why would you diff the whole website? The designer should be able to indicate the changes in the design and you just make those changes. If you can't do that, then don't worry about learning the art of design, instead learn html and css. – Brett East Apr 28 '17 at 13:31
  • I'm voting to close this question as off-topic because it should be on Software Engineering SE. – EJoshuaS - Stand with Ukraine Jul 18 '17 at 23:18
  • I'm voting to close this question as off-topic because it should be on Software Engineering SE – BDL Aug 10 '17 at 11:39
  • This question is off-topic because it is not within the scope of questions appropriate for this site, as defined in [What topics can I ask about here?](//stackoverflow.com/help/on-topic) Please also see: [What types of questions should I avoid asking?](//stackoverflow.com/help/dont-ask) You may be able to get help on [another Stack Exchange site](//stackexchange.com/sites#name). – Makyen Oct 01 '17 at 02:02

4 Answers4

7

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).

Preview
  • 35,317
  • 10
  • 92
  • 112
  • I'm asking what happens if the designer later updates the design. Should I redo all (or part) of the work already done? – Hedin Apr 24 '17 at 16:11
  • No, simply the updated part. With the react components architecture and since you own the code which is the most critical part, it's pretty straight-forward to know what needs to be changed. – Preview Apr 24 '17 at 16:13
  • Added this part in my answer. – Preview Apr 24 '17 at 16:30
  • Ok, I'm not asking the designer to do my job. I know HTML/CSS enough to copy and paste the changed part of the html file into React components. However, I don't **want** to do this each time the designer wishes to update the button shape, since I basically need to do the same work again. (Copy - Adapt for React - Paste a piece of HTML/CSS). – Hedin Apr 25 '17 at 16:54
  • If the designer updates the button shape, you won't have to adapt, nor paste html. You will just need to update the style properties of said button. That would be pretty fast. – Preview Apr 25 '17 at 16:55
  • This is understandable but still doesn't answer the initial question: is there a common methodology to avoid this. – Hedin Apr 25 '17 at 17:18
  • There it at-least 10 different questions in your OP, and now you're asking one more. I gave you my answer regarding a potential workflow with a dedicated designer and a React implementation, but I'm afraid you're looking for a holy grail. – Preview Apr 25 '17 at 17:31
6
  1. Get the html files
  2. Create the Router in React
  3. Migrate the basic Layout stuff into a Layout Component
  4. Migrate the pages content into PagesComponents
  5. Migrate common components into your ComponentsLibrary (Navs, Buttons, etc.)
  6. Replace the common html parts with the newly created Components
  7. 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.

webdeb
  • 12,993
  • 5
  • 28
  • 44
  • So, there is a Templater guy? – Hedin Apr 25 '17 at 16:51
  • 1
    Yeah, its better to work in the same scope/git repo, instead of Separation – webdeb Apr 25 '17 at 16:55
  • This far this is the closest to the answer I expected. – Hedin Apr 29 '17 at 12:25
  • 1
    well, I don't think there is a master way of handling it, your business will evolve every day, so in the first days you will do it manually, later other will do it for you, and after some time, your team will good enough with react, that you don't need to outsource HTML creation instead doing it in-house. – webdeb Apr 29 '17 at 14:14
  • So, the final answer here is: the designer must be a React developer himself. Am I right? – Hedin Apr 29 '17 at 16:20
  • No, to be a React developer and to know a relative simple subset of es/jsx stuff is not the same. The Designer or who ever is creating the html files for you, should just put them in a react application, as easy as putting it into the render function. 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. – webdeb Apr 30 '17 at 14:58
0

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! :)

Tzook Bar Noy
  • 11,337
  • 14
  • 51
  • 82
  • Well, this is basically what I'm asking, retold. In case the designer changes html/css which I already reformatted to fit my shiny new React structure, I'm going to have hard time finding out what really changed and patching it into the working code. So, I'm asking is there an accepted technique to minimize this overhead? – Hedin Apr 24 '17 at 16:04
0

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).

Anthony Cregan
  • 960
  • 11
  • 25
  • No, it is not. Please see my edit. – Hedin Apr 29 '17 at 12:25
  • Following your edit, I think i understand. The idea behind a react app is that it just consumes the data its fed, if it is to be manipulated then it sends a message back to the backend: 'Here - user X wants to do Y', the server then updates the data based on the instruction its received and then sends a message back to every client to say the data has been updated and they should rerender. With that being said, the idea would be that you wouldnt diff whats on the server, you'd wipe it away and replace it with the new client bundle generated when you made your changes to your client app. – Anthony Cregan Apr 29 '17 at 17:20