An embeddable React module for viewing and filtering system logs — speeds up diagnostics and takes part of the support burden off the core development team.
Â
Inside the internal desktop web application Deep Vision, the client needed a dedicated component for working with system logs. The user opens the log screen and sees a stream of events with the ability to quickly search, filter, and group records by level, source, time, or module. The interface lets users expand a specific entry, copy fragments, switch between different log sets, and keep their context as they navigate. The component had to work inside the existing application as if the internal team had built it from scratch.
Â
Deep Vision is a product company developing a complex internal desktop web application for its own teams and partners. The system handles a large volume of technical events, so log visibility is critical for stability, incident analysis, and ongoing product development. Before our involvement, log handling existed through temporary tools that didn't scale across the product. At the same time, the core Deep Vision team was focused on product-critical functionality and needed a delivery partner who could take a clear technical brief, design an embeddable component to their standards, and hand it over without extra rounds of rework.
Â
Need for an embeddable componentÂ
Â
The log viewer had to work as a self-contained module the client could embed in the main application — no architecture changes, no stack changes.
Â
Data volumeÂ
Â
Logs are generated in significant quantities, so the interface had to stay readable and not drop frames under scroll or filter pressure.
Â
Flexible filtering and searchÂ
Â
The component had to support several filtering dimensions and fast field-level search — without turning the UX into something overly complex.
Â
Dependency on the internal APIÂ
Â
The component runs on top of Deep Vision's internal API, which was already partially defined and evolving alongside the core product.
Â
Standards for interaction with the host applicationÂ
Â
The team had to agree up front on how the component receives data, sends events back, and is configured for different usage scenarios.
Â
Limited time from the core teamÂ
Â
Internal developers could only allocate a limited amount of time for review and coordination, so the delivery process had to be tightly structured and predictable.
Â
We designed an independent React log viewer component delivered as a library that can be embedded into the main Deep Vision application. It exposes a clear contract for data and configuration, and a clean event surface for integration with the client's existing navigation and analytics. For development and demonstration, a separate container application simulated the behavior of the host system.
Â
Log usage scenariosÂ
Â
With the Deep Vision team, we documented the key usage scenarios — viewing streaming logs, searching by keywords, filtering by severity and module, expanding a single record for detail. For each one, we defined the minimum required fields, the expected depth of detail, and the correct behavior under high-volume data.
Â
Component integration contractÂ
Â
We described the integration interface explicitly: which props the host application passes in (data, field schemas, filter parameters), which events the component emits back (onSelectLog, onFilterChange, onScrollEnd). The contract was designed to stay as stable as possible — the internal team can evolve the logging API without breaking the UI component.
Â
Frontend implementation of the log viewerÂ
Â
The component was built in React with list virtualization, so large volumes of logs render without lag. The interface structure is built around a table with expandable records, a filter panel, and a search area — with the visible column set adaptable per log type.
Â
Data handling and filteringÂ
Â
Filtering logic runs inside the component against configuration provided by the host. Combined filters, fast search, and baseline display normalization (date formatting, log levels, large payload fields) all work consistently across log sources.
Sandbox container applicationÂ
Â
For autonomous development, we built a lightweight standalone app that simulates the client's backend: generates test logs, mutates their states, and embeds the component exactly as the real system would. That isolated development from the main product and kept the Deep Vision team out of interim integration work.
Â
QA and documentationÂ
Â
The component is covered by unit and integration tests for the critical scenarios — filtering, virtualization, handling empty or invalid data. The technical documentation describes the component API, includes connection examples, and offers recommendations for configuring it across different system modules.
Â
At the start, we received the technical brief from the client and ran a clarification session with the Deep Vision developers. We broke the requirements into concrete scenarios — who uses the log viewer, which tasks it supports, which operations are critical, which are secondary. We aligned on the log types to support in the first version, the data refresh cadence, and the record volume users had to browse comfortably.
Â
The new log viewer became a ready-made building block for Deep Vision — embeddable across several modules of the internal application without designing a separate log UI for every use case. The team got a tool with predictable behavior that raises the bar on diagnostics and keeps the core developers focused on the main product.
Â
a clear component API, no host architecture changes
in one interface, replacing the ad-hoc tools and temporary internal solutions
no more time spent building and maintaining a specialized log UI
embeddable in other parts of the system or future products without rewriting the functionality
the documented contract and sandbox examples lower regression risk as the internal logging API evolves
Or send us a message and we'll get back to you within 15 minutes during business hours