I'm in an interesting position right now that I'm wondering how some of you other front end devs manage.
So I am a front end developer working with Angular, I tend to just use angular material for the design that has worked well up until now.
I'm in a situation now, where I'm working with a designer who wants to add custom HTML/CSS but has no interest or knowledge at all of the development.
So I have no interest in CSS, and they have no interest in learning the intricacies of Angular.
So, what are people's experiences with this and how do you manage it in a production project?
Assume the deployment of changes is irrelevant, I'm interested to know how work is managed from a day to day perspective.
Latest comments (8)
I have found that css is an art. It takes way longer than expected when custom work is needed. The html grid is wonderful and helps a lot. Advice...watch the boring css videos ad. Nauseum. The angular parts and component styling is easy. Its just bringing it all together in a custom way. Remember mobile first....
Interesting. So are you advocating me picking up more CSS knowledge and managing the whole stying/dev myself? Leaving the designer to just generate mock ups and leave me to implement?
Not really, you as the developer can focus on small component creation. Each component applying an over-ride-able style. As you build components and join them together that's where CSS expertise enters more than ever. It takes a while to understand it because the layout stytems don't talk at all.
Thanks for the input John, really appreciate it! I'm swaying more towards letting the designers manage a 'master' stylesheet that covers spacing/fonts/buttons/headers etc etc and then any nitty gritty stuff I can just manage myself.
Speaking for myself here: React and styled-components allows us to have such a level of componentization (is that a word?) that I tend to mix styles and logic on the same file. Components are so small and atomic that adding some styling won't collide with the logic of the app. In case some component breaks it's easy to identify and fix without breaking anything else.
Hope it helps!
Thanks for the response Guido. I'm currently in the middle of a React training course and that seems to allude towards keeping a small number of stateful components that control logic and having a lot more stateless dumb/presentation components.
I think that fits with what you're saying if I've understood correctly?
You got it perfectly! I have some "smart" components (with state, GraphQL queries, logic, etc) that act as a motherboard and a bunch of stateless components that would be switches and led lights which the user would interact with to control the motherboard.
Great analogy! Thanks for the input Guido, I really appreciate it.