Abdulrhman Al-Qassas

firstName

lastName

email

Stay up-to-date with my words

## Introduction

Front-end development is not only about making a page look good. A good interface should be clear, responsive, fast, accessible, and simple enough for another developer to understand later.

In my work with React, Vite, Tailwind CSS, React Query, Redux, and OpenLayers, I have learned that best practices are not abstract rules. They are small habits that prevent real problems: slow pages, duplicated logic, confusing state, broken mobile layouts, and code that becomes hard to change.

## Start with the User Flow

Before building components, I like to understand what the user is trying to do.

For a book review project, the important flow might be searching, browsing, and reading book details. For a geospatial project, the important flow might be finding a location, understanding map data, and taking an action. For a verification system, the important flow might be trust, clarity, and safe handling of information.

When the user flow is clear, the interface becomes easier to design and the code becomes easier to organize.

## Keep Components Focused

A component should have one clear responsibility. If one component handles layout, data fetching, form state, map setup, filtering, and styling, it becomes difficult to reuse or debug.

I prefer this structure:

```txt
components/
  ProjectCard.tsx
  SearchInput.tsx
  EmptyState.tsx
  map/
    OpenLayersMap.tsx
    markerLayer.ts
    mapStyles.ts
```

Small components make the project easier to scan. They also make it easier to improve the UI without touching business logic.

## Use the Right State Tool

Not every piece of data belongs in Redux. Not every API response belongs in local state.

My general rule is:

- Use local state for UI details like opened menus, form inputs, and active tabs.
- Use React Query for server data, loading states, caching, and refetching.
- Use Redux only for state that many parts of the app truly need to share.
- Use refs for non-React objects like an OpenLayers map instance.

This keeps state predictable. It also avoids unnecessary re-renders and duplicated API logic.

## Build Responsive Layouts from the Beginning

Responsive design should not be a final step. It should be part of the first implementation.

With Tailwind CSS, I usually start with the mobile layout, then add larger breakpoints only when the design needs them.

```tsx
<section className="grid gap-6 md:grid-cols-2 lg:grid-cols-3">
  {projects.map((project) => (
    <ProjectCard key={project.title} project={project} />
  ))}
</section>
```

A simple grid like this is easier to maintain than many custom media queries.

## Make Loading and Empty States Real

A polished project handles more than the happy path. Users should know what is happening when data is loading, when a search returns nothing, or when an API request fails.

For example, a book library should show:

- A loading state while books are being fetched.
- An empty state when no books match the search.
- A clear error state if the request fails.

These details make the application feel reliable.

## Write Clear Data Boundaries

Frontend code becomes cleaner when data is transformed before it reaches the UI.

Instead of formatting dates, fixing missing fields, and building labels inside every component, I prefer small helper functions:

```ts
export function formatProjectDate(date: string) {
  return new Intl.DateTimeFormat('en', {
    month: 'short',
    year: 'numeric'
  }).format(new Date(date));
}
```

This keeps components focused on rendering.

## Treat Accessibility as Part of Quality

Good UI should work with a keyboard, readable contrast, clear labels, and semantic HTML.

Some simple checks I use:

- Buttons are buttons, not clickable divs.
- Form inputs have labels, even when the visual label is hidden.
- Images have meaningful alt text when they communicate content.
- Focus states are visible.
- Text remains readable on mobile screens.

Accessibility is not separate from design. It is part of building a professional interface.

## Keep Map Interfaces Organized

Geospatial interfaces can become complex quickly. A map may include tile layers, markers, popups, search, filters, selected features, and drawing tools.

The best practice is to separate map concerns:

- Base layer setup.
- Marker or vector layer setup.
- Map interactions.
- UI controls outside the map.
- Data fetching outside the map rendering code.

This makes OpenLayers easier to use inside React and prevents the map component from becoming too large.

## Test the Build, Not Only the Browser

A page can look fine during development and still fail during production build. Static generation, TypeScript checks, imports, path handling, and content parsing can expose issues late.

That is why I like to run:

```bash
pnpm run build
```

before considering a change complete. A successful build gives confidence that the project can be deployed.

## Conclusion

Best practices are not about making code look complicated. They are about making the next change easier.

For me, good front-end work means building interfaces that feel smooth to users and stay understandable for developers. Whether the project is a React portfolio, a book review app, a blockchain verification system, or an OpenLayers map, the same principles apply: clear structure, focused components, thoughtful state, responsive design, and careful attention to real user workflows.


Front-End Best Practices I Use in Real Projects

Interactive map built with React and OpenLayers

## Introduction

Maps are one of the most useful interfaces in modern web applications. They turn location data into something people can explore, compare, and understand quickly. For a React developer working with geospatial products, OpenLayers is a strong choice because it gives you control over layers, projections, vector data, markers, interactions, and external map services.

This post walks through a clean way to build an interactive map with React and OpenLayers. The goal is not only to show a map, but to structure it so it can grow into a real application.

## Why OpenLayers?

OpenLayers is an open-source JavaScript library for rendering maps in the browser. It can display tile layers, vector layers, markers, GeoJSON, WMS, WMTS, and custom sources.

I like OpenLayers when the project needs more than a simple embedded map. It gives you enough control to build dashboards, location search, drawing tools, custom markers, route previews, and GIS-style interfaces.

## Core Concepts

Before writing React code, it helps to understand the three main pieces.

### Map

The map is the main OpenLayers object. It connects the HTML element, layers, view, and interactions together.

### View

The view controls the center, zoom level, and projection. Most web maps use `EPSG:3857`, so coordinates usually need to be converted with `fromLonLat`.

### Layers

Layers define what the user sees. A map can have a base tile layer, vector layers for features, marker layers, and image layers. Keeping layers separate makes the map easier to maintain.

## Install OpenLayers

```bash
npm install ol
```

If your project uses pnpm:

```bash
pnpm add ol
```

## Create a Reusable Map Component

The most important React rule is simple: create the OpenLayers map once, then update it intentionally. Do not recreate the map on every render.

```tsx
import { useEffect, useRef } from 'react';
import Map from 'ol/Map';
import View from 'ol/View';
import TileLayer from 'ol/layer/Tile';
import OSM from 'ol/source/OSM';
import { fromLonLat } from 'ol/proj';
import 'ol/ol.css';

export function OpenLayersMap() {
  const mapElementRef = useRef<HTMLDivElement | null>(null);
  const mapRef = useRef<Map | null>(null);

  useEffect(() => {
    if (!mapElementRef.current || mapRef.current) return;

    mapRef.current = new Map({
      target: mapElementRef.current,
      layers: [
        new TileLayer({
          source: new OSM()
        })
      ],
      view: new View({
        center: fromLonLat([31.2357, 30.0444]),
        zoom: 10
      })
    });

    return () => {
      mapRef.current?.setTarget(undefined);
      mapRef.current = null;
    };
  }, []);

  return <div ref={mapElementRef} style={{ width: '100%', height: 480 }} />;
}
```

This component is small, but it already has the right foundation: the DOM target is stored in a ref, the map instance is stored in a ref, and cleanup happens when the component unmounts.

## Add Markers with a Vector Layer

Markers should usually live in a vector layer. That keeps marker data separate from the base map and makes it easier to add selection, hover states, clustering, and styling later.

```tsx
import Feature from 'ol/Feature';
import Point from 'ol/geom/Point';
import VectorLayer from 'ol/layer/Vector';
import VectorSource from 'ol/source/Vector';
import { Circle, Fill, Stroke, Style } from 'ol/style';
import { fromLonLat } from 'ol/proj';

const marker = new Feature({
  geometry: new Point(fromLonLat([31.2357, 30.0444])),
  name: 'Cairo'
});

marker.setStyle(
  new Style({
    image: new Circle({
      radius: 7,
      fill: new Fill({ color: '#2563eb' }),
      stroke: new Stroke({ color: '#ffffff', width: 2 })
    })
  })
);

const markerLayer = new VectorLayer({
  source: new VectorSource({
    features: [marker]
  })
});
```

You can add this `markerLayer` to the `layers` array when creating the map, or add it later with `map.addLayer(markerLayer)`.

## Keep React State and Map State Separate

OpenLayers has its own state system. React also has state. Problems start when both try to control the same thing too often.

A good pattern is:

- Store the map object in a ref.
- Store UI state in React.
- Use effects to sync deliberate changes from React into OpenLayers.
- Listen to OpenLayers events only when you need user-driven updates.

For example, if you want React buttons to change zoom:

```tsx
function zoomIn() {
  const view = mapRef.current?.getView();
  const zoom = view?.getZoom() ?? 0;
  view?.animate({ zoom: zoom + 1, duration: 200 });
}
```

This keeps the map responsive without forcing React to re-render the whole map.

## Suggested File Structure

For a real project, I prefer separating map setup from data and UI.

```txt
src/
  components/
    map/
      OpenLayersMap.tsx
      mapStyles.ts
      markerLayer.ts
      useMapInteractions.ts
  data/
    locations.ts
```

This makes the map easier to test and easier to extend when the project grows.

## Best Practices

Use `useRef` for the map instance. The map is not normal React state and should not trigger re-renders.

Clean up with `setTarget(undefined)`. This prevents memory leaks when moving between pages.

Normalize coordinates early. Keep longitude and latitude clear in your data, then convert them at the map boundary with `fromLonLat`.

Separate layers by responsibility. Base map, markers, drawings, selected features, and overlays should not all live in one layer.

Avoid putting too much logic in one component. A map can become complex quickly, so split styling, layers, interactions, and data loading into small modules.

## Conclusion

React and OpenLayers work very well together when each tool has a clear job. React should manage the page, controls, and data flow. OpenLayers should manage the map rendering, layers, and geospatial interactions.

That structure gives you a map that is smooth for users and maintainable for developers. It is the same mindset I use when building front-end experiences: start with a simple working foundation, then keep every new feature organized enough to grow.


Blog

Front-End Best Practices I Use in Real Projects

How to Build an Interactive Map with React and OpenLayers