Skip to content
  • Unlock Pro
  • Log in with GitHub
Solution
Submitted 26 days ago

IP Address Tracker

Jonathan Peters•230
@QMS85
A solution to the IP Address Tracker challenge
View live sitePreview (opens in new tab)View codeCode (opens in new tab)

Solution retrospective


What are you most proud of, and what would you do differently next time?

Here's what I'm most proud of and what I'd do differently...

What I'm Most Proud Of...

  • Accessibility Implementation:
    The project includes comprehensive accessibility features like ARIA labels, live regions for dynamic content updates, semantic HTML structure, and proper focus management.
    The visually-hidden labels and descriptive attributes make it usable with screen readers.

  • Responsive Design:
    The CSS grid layout that adapts from single column on mobile to 4 columns on desktop, with thoughtful breakpoints and mobile-first approach, ensures great user experience across all devices.

  • Clean Architecture:
    The JavaScript uses a well-structured class-based approach with clear separation of concerns - initialization, event handling, map management, and data updates are all properly organized.

What I'd Do Differently Next Time...

  • Real API Integration:
    Instead of mock data, I'd implement actual IPify API integration with proper error handling, rate limiting, and fallback mechanisms for when the API is unavailable.

  • Enhanced Error Handling:
    Replace the simple alert() with a more sophisticated error display system - perhaps a toast notification or inline error messages that are accessible and user-friendly.

  • Performance Optimization:
    Add debouncing to the search input to prevent excessive API calls, implement caching for recent searches, and lazy load the map to improve initial page load time.

  • Testing Coverage:
    I'd add unit tests for the IPTracker class methods and integration tests for the search functionality to ensure reliability and make future maintenance easier.

What challenges did you encounter, and how did you overcome them?

Regarding this IP Address Tracker project, here are the main challenges I encountered and how I overcame them...

  1. Map Integration & Custom Markers...
    My Challenge:
    Integrating Leaflet.js and creating custom markers that match the design while ensuring proper positioning and responsiveness.
    My Solution:
    I Used Leaflet's divIcon to create custom HTML-based markers with CSS styling, and implemented proper marker management with removal/addition logic to prevent duplicates.

  2. Responsive Layout with Overlapping Elements...
    My Challenge:
    The info panel needed to overlap the header background while maintaining responsive behavior across all screen sizes.
    My Solution:
    I Used negative margins (margin-top: -4.5rem) with proper z-index layering, and implemented CSS Grid that adapts from 1 column on mobile to 4 columns on desktop.

  3. API Integration Architecture...
    My Challenge:
    Designing a flexible system that works with mock data for demonstration but can easily integrate with real APIs later.
    My Solution:
    Created a clean separation between data fetching and display logic, with a getMockData() method that can be easily replaced with actual API calls to IPify.

  4. Accessibility Implementation...
    My Challenge:
    Making the map and dynamic content accessible to screen readers while maintaining the visual design.
    My Solution:
    I Implemented ARIA live regions for dynamic updates, visually-hidden labels, semantic HTML structure, and proper focus management throughout the interface.

  5. Form Handling & User Experience...
    My Challenge:
    Providing immediate feedback during searches while handling both form submission and Enter key events properly.
    My Solution:
    Added loading states with button/input disabling, implemented proper event handling for both form submission and direct keypress events, and created visual feedback for user actions.

The key to overcoming these challenges was breaking down complex problems into smaller, manageable pieces and focusing on progressive enhancement - starting with a solid foundation and adding features incrementally.

What specific areas of your project would you like help with?

Here are the specific areas where I'd most value feedback and assistance...

  1. Code Architecture & Best Practices...
  • JavaScript Class Structure:
    I'd like feedback on whether the IPTracker class organization is optimal. Specifically:
    A. Is the separation between initializeMap(), bindEvents(), and data handling methods clear enough?
    B. Should I break down the searchIP() method further for better single responsibility?
    C. Are there any JavaScript design patterns I could implement to make the code more maintainable?
  1. Error Handling & User Experience...
  • API Integration Strategy:
    The current mock data system works for demo purposes, but I'd appreciate guidance on:
    A. Best practices for transitioning from mock data to real IPify API calls
    B. How to implement proper rate limiting and caching strategies Whether my current error handling approach (alert() fallback) should be replaced with something more sophisticated like toast notifications or inline error displays
  1. Performance Optimization
  • Map Rendering & Responsiveness:
    I'm particularly interested in feedback about:
    A. Whether the Leaflet.js initialization and marker management could be optimized further
    B. If the current responsive breakpoints (375px, 768px, 1024px, 1440px) provide the best user experience across devices
    C. How to improve initial page load performance, especially with the map library
  1. Accessibility Implementation
  • ARIA and Screen Reader Support:
    While I've implemented basic accessibility features, I'd value input on:

A. Whether the current ARIA live regions for dynamic content updates are sufficient
B. If the custom marker implementation maintains proper accessibility standards
C. Any accessibility edge cases I might have missed in the search form or map interaction
5. CSS Grid & Layout Consistency

  • Info Panel Responsive Design:
    The grid layout transitions from 1 to 2 to 4 columns, but I'd appreciate feedback on:

A. Whether the visual hierarchy remains clear at all breakpoints If the overlapping header/info panel design could be more robust
B. Any CSS Grid improvements that could simplify the responsive logic

These are the areas where targeted feedback would help me elevate this project from a working demonstration to production-ready code.

Code
Loading...

Please log in to post a comment

Log in with GitHub

Community feedback

No feedback yet. Be the first to give feedback on Jonathan Peters's solution.

Join our Discord community

Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!

Join our Discord
Frontend Mentor logo

Stay up to datewith new challenges, featured solutions, selected articles, and our latest news

Frontend Mentor

  • Unlock Pro
  • Contact us
  • FAQs
  • Become a partner

Explore

  • Learning paths
  • Challenges
  • Solutions
  • Articles

Community

  • Discord
  • Guidelines

For companies

  • Hire developers
  • Train developers
© Frontend Mentor 2019 - 2025
  • Terms
  • Cookie Policy
  • Privacy Policy
  • License

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

Oops! 😬

You need to be logged in before you can do that.

Log in with GitHub

How does the accessibility report work?

When a solution is submitted, we use axe-core to run an automated audit of your code.

This picks out common accessibility issues like not using semantic HTML and not having proper heading hierarchies, among others.

This automated audit is fairly surface level, so we encourage to you review the project and code in more detail with accessibility best practices in mind.

How does the CSS report work?

When a solution is submitted, we use stylelint to run an automated check on the CSS code.

We've added some of our own linting rules based on recommended best practices. These rules are prefixed with frontend-mentor/ which you'll see at the top of each issue in the report.

The report will audit all CSS, SCSS and Less files in your repository.

How does the HTML validation report work?

When a solution is submitted, we use html-validate to run an automated check on the HTML code.

The report picks out common HTML issues such as not using headings within section elements and incorrect nesting of elements, among others.

Note that the report can pick up “invalid” attributes, which some frameworks automatically add to the HTML. These attributes are crucial for how the frameworks function, although they’re technically not valid HTML. As such, some projects can show up with many HTML validation errors, which are benign and are a necessary part of the framework.

How does the JavaScript validation report work?

When a solution is submitted, we use eslint to run an automated check on the JavaScript code.

The report picks out common JavaScript issues such as not using semicolons and using var instead of let or const, among others.

The report will audit all JS and JSX files in your repository. We currently do not support Typescript or other frontend frameworks.