Hi all, Would love to hear your thoughts about separation of concerns with using React. I recently set down with a client who considered using react in their workflow. The company has a team of Node.js developers and they use handlebars. I pitched the idea of isomorphic react enjoying server-side templating for SEO and faster initial loading time while also rendering on the client with a better data flow and performance.
Their main concern was dealing with the team in charge of design, css and html. They are looking for a way to interface with htmlists allowing them to focus on their CSS and not forcing them to learn react as they want to deal with the architecture logic. It seems like there is some what of an overlapping.
Assume the designer does html markup and css and they need to interface with a front-end JS developer to turn it into React components, add logic, most probably Redux etc...
Assume the designer WILL make changes to the markup and CSS and we need to have a workflow that will be able to introduce changes easily. Can you share similar thoughts or situations?
Cheers
Ajar
Ricardo Memoria
IT Consultant and developer
I agree with @apertureless. Designers should also have basic understanding of how React components work. This will speed things up and help developers and designers collaborate in a better way. The following workflow may work, but I would love to see what others recommend :
render() function that returns a dummy markup) and pass those to designers.render() and do whatever they want. If designers write HTML separately and developers write corresponding React components, it may introduce additional complexity while introducing changes. Doing everything in components is the right way, imo.
Well first of all, the Designers should definitely take a look into how React works. And have a basic understanding. As the Designers are doing the HTML and CSS and not the Frontend Dev, they should've some basic technical understanding of how things work.
The cool thing with React is, that you are working in components. And this is also a very important point for the designers (frontendlers), because they need to learn how to design and markup modular components.
So they are basically two ways around this.
Markup all the things. So the designers coding the components, Markup and Styling and hand them over to the frontend devs which are building the react components.
The important part is now, if something changes.
However this is only important if they change markup. Style changes can be made normally in the css file.
I can recount my early days of programming, a world where HTML, CSS and JS weren't invented yet. All apps were built using Windows APIs and/or Microsoft Foundation Classes. Did we have such debates then?
Well, no. Designers did their design in Photoshop or equivalent, and it was the job of the developer to translate it into code. Whether they used resource files (equivalent of HTML/CSS) or created widgets on the fly (equivalent of runtime creation of DOM elements using javascript) was not of concern to the designer. Some designers even created resource files themselves, but they did not need to know how to code, the resource editor did that for them. This saved both the designer and the developer some time and prevented transmission errors.
Fast forward to today. One problem is that HTML/CSS/JS was invented for laying out WWW content and hyperlinking, not for apps with great UI. Tools (equivalent of the resource editor) don't exist, and laying out UI has become more complicated, requiring code.
I believe HTML and CSS is code, and therefore, not the forte of designers. It's the job of developers to convert design to CSS or React Components or whatever. Only some developers will be good at this. That's reality. Others will be called backend engineers.
The same was applicable 30 years back. If designers messed with resource files, they ran the risk of breaking code that assumed something, like resource IDs and a particular hierarchy of components. So, designers who did generate resource files didn't touch it after they handed over the initial version.
If your designers produce markup and CSS, great. That's good for all. If they want to mess with it after the developers have integrated it, I'd say they are brave. In which case, they should be brave enough to learn to do it the React way if required.
But I'd really avoid it, and hire front-end developers instead.
I don't like React. Mix together styling and code it's just a bad idea that remembers me an evil and fortunately bygone era. If someone ask me I just say: use Riot or Vue: more elegant, easier but still powerful solution.
IMO today we are in a transition time on front-end development. HTML, JS and CSS has evolved a lot and the traditional way of building front-end separating design and implementation must evolve as well.
Particularly, I see the front-end moving to a component way of development (like React and other frameworks do). Who creates a date-time picker from scratch today? When we think about components, it makes sense to combine JS, HTML and CSS in one single stack for that component, and this way of programming goes against the traditional HTML+CSS design.
My current project uses React + Bootstrap + webpack + ES6. I'm very happy with that, but I see no other way of integrating designers but introducing them to React.
Designers don't need to know React deeply, but at least declare a new component and implement its basic render reusing other components - that won't hurt much.
But using React or not, I can't see designers not using a lot of JS. Just check the amount of JS code that comes with these Bootstrap templates.