Best Practices
Working with Sitecore
- Always have a POC as an HTML file in initial output
-Preferably shown at page level based upon designed composition - Stay in sync with Sitecore developers to avoid confusion and re-work
- All project files are shared between Sitecore and UI developers
- Avoid creating new components if possible
-Utilize option of adding classes to SCORE components
-If a new component must be introduced, talk to Sitecore developer
-Any new component styles should be saved in "site" folder
(custom-component-name.less) - Keep HTML sandbox files up to date with production
- Use browser extensions to test local CSS on production pages
-CSS Inject, CSS Reloader, Web Developer, etc.
- Always have a POC as an HTML file in initial output
Where to start?
- Two approaches to begin project development
-Front end first, back end last (you write HTML)
-Back end first, front end last (you are given HTML) - Determing factors:
-Budget
-Time contstraints
-Resources
-Team preference - Decide whether to build whole pages with components or build stand alone components
- Two approaches to begin project development
Pros and Cons: Front-end First
Pros:
- Solid POC from beginning (show progress to clients, designers, team members)
- Point out design flaws early in the process
- Sitecore devs have a good foundation to start their development
- Design assets are implemented from the start (image cropping, scaling, saving to project folders)
Cons:
- Potential re-work after page is built in Sitecore
- Potential wasted file space with unused styles
- More pressure on front-end for usable markup
Pros and Cons: Back-end First
Pros:
- Back-end devs have total control over markup
- Saves time and effort from front-end perspective
- Limited front-end involvement at the beginning of the project
Cons:
- More pressure on back-end for usable markup
- Sitecore devs have limited visibility with design
- Potential for HTML re-work after it reaches front-end stage
Code Organization
- Keep Less files organized and tidy
-Prevents code bloat and allows code to be easily understood or worked on by another team member - Stay DRY!
-Do your best not to repeat specific styles or blocks of code
-Use global variables and mixins that can easily be updated and maintained - Keep nesting under control
-Maximum of 4 levels deep if possible
-Styles under highly specific selectors are hard to override in other places - We recommend NOT changing any Bootstrap LESS files
- Keep Less files organized and tidy