DEV Community: Olawale Bashiru

Ever wondered why the features your favorite product promises often take longer than planned? Or why it sometimes feels like engineers deliver more promises than features? Considering how disappointing it feels, experiencing both sides of that letdown has taught me how crucial it is to deliver on time and with high quality.
Developer tooling is one of the core elements that impact delivery speed. The capacity of a developer is enhanced by great tools, such as the many hands of modern AI-powered workflows that enable us to accomplish more with less effort.

For frontend engineers, a core metric of their efficiency in replicating designs is how it looks on laptops, tablets, mobile devices, and large monitors: a phenomenon known as responsiveness. To achieve this, we define breakpoints: width thresholds that tell our layouts when to adapt.

Here's the catch, though: during implementation of a design, browser debugging tools don’t show which breakpoint is currently active. Developers have to cross-check window widths or manually inspect styles, a tiny task that makes each design review and QA cycle longer than necessary. This desire to maximize the efficiency of determining breakpoints sparked the inspiration to build Breakpoint Overlay: a small, yet effective widget that provides real-time responsiveness transparency.

From Frustration to Functionality

Once this gap was verified, I started looking for a way to increase productivity without interfering with my workflow. I wanted a tool that would be easy to use and integrate into my current workflow. Upon exploring existing options, it became clear that most required installing an entirely new browser just to work. That felt excessive. Switching tools comes with steep learning curves and uncertain trade-offs, so I aimed for minimal change and maximum impact.

That realization inspired me to build one myself, not just for me, but for others who care about speed, precision, and simplicity.
Once I had a clearer sense of how the tool should integrate, the next challenge was figuring out what it should feel like. I experimented with modal, sidebar, and persistent panel presentation models, but none of them felt light enough. I eventually settled on a badge overlay, a tiny, unobtrusive widget that quietly lives on top of your project without altering its flow.

The badge uses soft, muted colors to stay out of the way visually. In its collapsed state, it shows the active breakpoint, viewport size, and screen density. When expanded, it reveals a full list of user-defined breakpoints, a compact, focused display that respects the project’s aesthetic while delivering just enough information at a glance.

Once the design direction was set, I outlined functionality that would make it genuinely useful, not just visually informative. A small example is a keyboard shortcut to toggle the overlay’s imperative handlers, allowing developers to show or hide it instantly during workflow.

After settling on the idea and features, I turned my attention to the implementation specifics, which are what make a tool either a habit or a toy. In any setting, I wanted Breakpoint Overlay to be portable, dependable, and simple to use. A few guiding principles shaped this stage:

Core Concepts

Zero dependencies: Keeping it dependency-free ensures the widget stays lightweight and avoids conflicts within complex build chains.
Modularity: Each slice of implementation manages a distinct task, creating a unified system that is simple to test and expand.
Layered testing: To guarantee that its behavior continuously complies with design intent, each significant module has specific test coverage.

Key Technical Decisions

Resize Event vs. ResizeObserver: ResizeObserver does not alert users when the viewport height changes, despite being excellent for tracking content changes. To address this, I used a throttled window.resize handler, ensuring reliable breakpoint detection without performance loss.
Shadow DOM: Style and DOM leaks are common when multiple scripts share the same document tree. To avoid unintended collisions and maintain strict encapsulation, the widget renders inside its own Shadow DOM.
requestAnimationFrame: For smooth and efficient updates, the overlay throttles resize computations using requestAnimationFrame. Older updates are cancelled so the tool always reflects the most recent screen state, a simple but powerful performance win.

Each of these decisions reflects the same philosophy that started the project: efficiency through empathy, both for the developer’s workflow and the product’s integrity.

Reflections and Learnings

Charting unfamiliar territory always comes with unique challenges. Determining the minimum viable product (MVP) was a persistent problem for Breakpoint Overlay, just like similar projects.

The idea started simple: track the active breakpoint. But my curiosity got the better of me; I continued to experiment, adding other "cool-to-have" features, reporting container queries, and highlighting overflowing content. New user-experience choices, implementation specifics, and testing considerations arose with every addition. This pursuit for perfection can lead to an unending cycle of development, as was soon discovered.

Snapping out of that obsession was one of the most important lessons of the project. I discovered how to deliver a minimal version that addressed the correct issue first and to put impact ahead of complexity.

Beyond scoping features, there were challenges rooted in unfamiliar technologies. Setting up the project as a monorepo, a single repository managing multiple applications and their dependencies, was new to me. While leaving room for upcoming additions like documentation and integration examples, it was crucial for separating the widget's package, demo app, and configuration files.

These conflicting moments served as stepping stones. Every obstacle revealed a learning gap, and each gap led me back to documentation, community forums, AI research tools, and the open web—a reminder of how collaborative modern development really is.

Looking ahead, I envision Breakpoint Overlay evolving beyond its current functionality. Consider innovative adapters for popular design systems or a movable widget that can be positioned in any viewport corner. More than features, though, this project taught me that building well is about knowing what really matters and not just about adding more.

In the end, Breakpoint Overlay became more than a tool. It became a reflection of curiosity, restraint, and the constant pursuit of better ways to build.

Closing Thought

Every line of code in Breakpoint Overlay carries a lesson about design empathy, deliberate constraint, and the quiet power of developer tools.

Because sometimes, innovation isn’t about doing more; it’s about making what you already do feel effortless.

If you’ve ever wished for a simpler way to see which breakpoint your app is using, check out Breakpoint Overlay.

It’s open source, dependency-free, and available on both GitHub and npm. Feedback, suggestions, or contributions would be greatly appreciated, especially from engineers who share my passion for the developer experience.

Role of Cryptography in Secure Digital Communication and Software Development.

Olawale Bashiru — Sat, 20 May 2023 18:50:20 +0000

Ensuring safe digital communication may seem so simple at its core, yet can be the bane of a product's survival in the ever evolving market. This may seem like an overstatement, but when the risks are fully considered, it becomes apparent why so much money and effort is invested to evolve security practices and mitigate new risks as they are discovered. At the core of ensuring safe communication, lies one of the fundamental building block, Cryptography.

Cryptography can simply be defined as the practice of applying techniques to conduct secure data communication in the presence of adversaries. The key principle of cryptography is to ensure confidentiality, integrity and authenticity during communication.

TLDR: Cryptography is one of the core building blocks for secure communication in software development.

Core principles

Confidentiality: act of concealing data from unauthorised access.
Authenticity: ability to trace data identity back to its origin of creation.
Integrity: concept of determining if data has been altered since its creation.

Methodologies

There are several techniques upon which security of data is ensured, below is a brief summary of some of this concepts:

Hashing

This is a pattern of encoding data in cipher text such that the process is deterministic, irreversible, and collision resistant.
In simpler terms, this means that no data, plain text for example is redeemable from its encoded cipher text, making it an irreversible process.
Different cipher texts are formed for any slight change in the value of the plain text, hence deterministic.
Collision resistant refers to its ability to create a unique cipher value for every plain text hashed, ensuring that no two plain text have the same cipher text.

The cipher text, also known as hash is created by unique algorithms that are designed to operate by relying on specific mathematical theories. Examples of such theories are the discrete logarithmic problem and modular arithmetic.
One application of hashing can be illustrated in Public Key Cryptography, a pair of related key values that include a public and a private key. The public key is generated from the private through hashing.
By leveraging on cryptographic hashing, other important techniques have been designed, such as checksums and digital signatures.

Checksums

These are small values generated from the cryptographic hashing of specific data, typically much larger than the checksum itself.
The process of generating a checksum is a simple process, aimed at ascertaining the integrity of data during transmission or storage.
This is important because, some of the data may be accidentally misplaced or otherwise corrupted.
Its simplicity makes computing its integrity easy and efficient to ascertain.
It is typically used by data storage and transmission systems to enforce efficiency of the process.
Although they aren't a full proof solution to data security, they are useful for preserving data integrity.

Public Key Cryptography

This is an application of cryptographic hashing that consists of a Public Key, a Private Key and a Signature.
The public key is a value that serves as a means of public identity for its corresponding secrete private key.
Private keys are kept secret specifically for the power that it wields. Unauthorised access to a private key enables the possessor to impersonate the actual owner of the key.
By convention, private keys are generated from randomly generated data to maximise its security. Digitally, this randomness is simulated by relying on algorithms known as pseudorandom number generators.
Although private keys can be generated manually, this may compromise its security, hence advised against.
The private key can be used to form a binding relationship between the Public key pair and a signed piece of data, producing a corresponding signature.
Using the public key, the signed data, and the resulting signature, the authenticity of the signed data can be verified by any third party without accessing the private key.
This means that the signed piece of information can be verifiably proven to originate from the public key pair without the owner ever disclosing the private key, therefore establishing trust.
There are various types of digital signatures, each formed from by unique algorithms. Examples are the Elliptic curve digital signature(ECDSA) and Knorr signature.

Data Encryption

This is a cryptographic technique specifically aimed at enforcing confidentiality of data.
It is the process of encrypting or encoding data as cipher text such that it is confidential, reversible, yet difficult to decode by unauthorised adversaries.

This process is not aimed at preventing interference during transmission of data, rather it is designed to ensure intelligibility to any unauthorised interceptor.
This is achieved by using a secret key during the encoding of the data to secure it.
There are two forms of commonly used encryption techniques, Symmetric and Public-key encryption.
Symmetric encryption involves the use of the same key to encrypt and decrypt data, hence they’re easier to compute in comparison to Public-key encryption.
Public-Key encryption, also known as Asymmetric encryption, employs the use of a public key cryptography to encrypt data.
This is achieved by using a public key to encrypt data, such that only the bearer of its private key can decrypt it.
Because of this additional layer of separating concern, they offer more security, and as a result require more computing resource than symmetric encryption.
Ideally, data encryption does not guarantee full proof security from interceptors, but a well encrypted data will require a good amount of both skill and computational resource to decode without the required secret key.
Authorised decoding of encrypted text with the secret key on the other hand is as easy as cracking a nut, requiring relatively much lesser computational resource.

Practical Applications

Transport Layer Security (TLS)

This is a Cryptographic protocol that ensures security of transit data over networks.
It operates by providing end to end security of data sent between applications over the internet.
It leverages the cryptographic encryption of data during transit.
This encryption includes both Symmetric and Asymmetric types to maximise security.
A random session key is generated for the transmission session by the client.
It further uses the server's public key to encrypt it such that the server can only decrypt this session key using its private key, and transmits it to the server.
Upon receival and decryption of the session key by the server, both participants would bear the session key in their possession.
Further communication would then be encrypted and decrypted with the session key.
It is used in applications such as email, VOIP, instant messaging, DNS and web applications.

Data storage

The secure storage and transmission of data is one of the most important factors to consider when building software products.
A “minor” breach of data, either due to unauthorised access or accidental corruption can mar the reputation of any product.
The detriment of this risk is why software developers apply a combination of techniques to maximise security and ensure integrity.
An example is in the encryption of data during transit, between a client and its server, rather than leveraging only on network security. This additional measures further reinforces data protection.
Data hashing prior to storage is another means of storing extremely sensitive information, by reducing risk of exposure upon a breach. This pattern of storing hashes rather than actual data provides an elevated level of security to sensitive data. It is frequently applied in the storing of passwords and credit card information.
Lastly, Checksums are frequently used to establish the integrity of data at various point during its lifecycle.

JSON Web Token (JWT)

This is a mechanism designed to communicate authenticity of any entity, such as a user, by ascertaining their identity.
JWT is a standard for representing claims of ownership in modern applications.
It provides a secure alternative to storing login credentials such as username and passwords, on servers after initial authorisation, to verify future claims.
After the user's initial authorisation, a token is generated by the server.
This token is generated from the claim, such as a user’s credentials and an additional secret, known only to the server.
The token consists of three integral parts, namely an header, payload and signature.
The header contains the type of token created and the hashing algorithm used to create the signature.
The payload contains the claim, such as the identity of the user in this scenario.
While the signature is the cryptographic hashing of the header, payload and the secret data, known only to the server.
This token can then passed around back to the requesting client for use.
Whenever the client requires further access to any protected resource, alongside its request for the resource, it presents the previously received token for authentication.
Upon receiving this request, the server verifies the authenticity of the token, then grants access if successful.
JWT introduces better efficiency by removing a round trip, that would have been used by the server to authorise access requests with login credentials.

Decentralised systems

Thanks to recent boom in popularity of Bitcoin and decentralised systems in general, cryptography has gained massive popularity, prompting many to believe it is a recent innovation.
Decentralised systems are designed such that they rely heavily on the super powers of cryptography to function.
This results from the decentralised approach to authority in the system.
What this means simply is that unlike centralised systems which rely on a central authority for trust, to verify claims, or direct the affairs of the system, participants of most decentralised systems operate at the same level of control, with no participant ranking higher in authority than another.
This design to decentralise trust by distributing control, also prevents censorship of participation, promotes transparency, maximises both scalability and resillience of the system.

To enforce trust in a trustless system, cryptography is leveraged, from public key pair identities, to transactions integrity, authentication of claims, to network wide state consensus, creation of currency and much more.
The application of cryptography is evidently the glue that holds the several moving components of decentralised systems, operating efficiently as one.

Conclusion

I hope that with these few ramblings of mine, I have been able to successfully convince you and not confuse you of the importance of security in digital communication, the role of Cryptography and the need to ensure strict adherence to best security practices during software development.

Sources

Encryption
Cryptography Digital signatures
TLS Basics
JW Token
What Is JWT and Why Should You Use JWT
How Is Cryptography Used In Applications?

How my obsession drove me to re-engineer a different type of FlatList, I called it "NestedLists".

Olawale Bashiru — Thu, 20 Oct 2022 09:57:54 +0000

An exercise that started out as an effort to replicate a screen from one of the most used social media applications by leveraging on the React Native framework turned out to be a lot more work than I had originally anticipated. I assumed all I had to do was to slap a few React Native elements together with their appropriate styling and “Tada!”, I could applaud myself for a job well done. Little did I know of the impeding bottleneck patiently awaiting me.

Eager to complete the necessary work as quickly as I could, I dived right in to constructing a mental model of how the layout should be structured. This is my intuitive approach to implementing designs; I never go wrong with breaking complex designs into fundamental core components needed to achieve desired layout.

I concluded on an approach which required nesting FlatLists. In total, there were four of them.

One grandparent vertical FlatList where the three remaining FlatLists and other necessary components will be nested.
One child horizontal FlatList where the remaining two Flatlists will be nested directly in. This enables easy horizontal scrolling between the other nested lists.
The last two grandchildren FlatLists are vertical lists where the image items are nested directly in.

I implemented the mockup immediately and the gotcha became obvious. The problem with this approach was that Scrolling of the nested vertical FlatLists’ content was impeded when the pan was initiated directly in the grandparent vertical FlatList region and vice-versa. It became apparent that my traditional approach to implementing the layout was most likely not achievable. I spent hours trying to research ways to circumvent these limitations but every suggestion introduced a certain trade-off in the desired UX.

To provide more context into the desired UX, a scroll in the composite component should be able to pan any available content in the direction to which it is being moved, continuously; regardless of whichever specific FlatList the content was nested directly in.

Having nested vertical FlatLists with impeded scrolling during content panning was not an acceptable bargain; hence I was prompted to take a not so little detour of building a list that could seamlessly fulfil my layout and UX requirements.

NestedLists

Prior to this exercise I had very limited experience using gesture responders. Although I had basic understanding of React Native’s Gesture Responder System, I had no experience using the more elaborate React Native Gesture Handler. I dived straight into their documentations to get myself armored up to defeat my enemies, I couldn’t afford to be put to shame by mere inanimate objects. 😅

One of my first impressions was the vast difference in ease of usage of the React Native Gesture Handler in comparison to React Native’s Gesture Responder System. One less obvious impression was how React Native Gesture Handler’s seamless integration with React Native Reanimated transformed fluidity and complexity of animations. Hence, I concluded on leveraging on the power boost from the duo. Armed to the teeth with weapons of mass destruction, I proceeded on the journey to build NestedLists. 😂

NestedLists Features

Its layout is structured to have two regions, a header region where the “grandparent FlatList” content (a.k.a NestedLists header) is rendered and a nested lists region where the “grandchildren FlatLists” (a.k.a Nested Lists) are rendered.
Scrolling between the nested lists is achieved by a horizontal swipe in the nested lists region of the component. Panning the entire lists content must complete seamlessly between regions without any restriction in movement.
Scrolling to the NestedLists header region from any of the nested lists, scrolls other nested lists to the top of their content.
Each nested list’s height is solely dependent on the height of its own content
Refreshable - nested lists content should be refreshable
Dynamic content loading – nested lists should be able to load more content upon scroll to end.
Scalable - NestedLists should exhibit features specified above efficiently regardless of the number of nested lists.

Using React Native Reanimated and React Native Gesture Handler, I created animated values (a.k.a Shared Values) which reacted to gestures and drove the animation of Animated Views during scrolling. The Animated Views contained components of NestedLists and were transformed using their “translateX” and “translateY” style property upon update of their animated values.

Using reactive hooks from React Native Reanimated such as “useAnimatedReaction” and “useDerivedValue”, I updated animated values when conditions for their update were met. These conditional updates were key to ensuring the desired UX was achievable.

Performance

To test the performance of NestedLists, I completed my implementation of Instagram’s profile screen and checked if it fulfilled the requirements it was built for. My observations were:

It loads more content dynamically by triggering the “onEndReached” prop provided to it when it reaches towards the end of the list.
It calls the “onRefresh” prop provided to the list, refreshing the active nested list’s content upon trigger.
It has as an optional nested lists sticky header which remain visible at the top of the nested lists, when the NestedLists Header have been panned out of view.
It provides an optional nested lists footer which can be used to indicate loading of more content when necessary.
It also fulfilled the desired layout and UX requirements earlier stated.

I also wondered how performant it functioned so I tracked the JS and UI thread FPS ratings of the Instagram profile screen implementation, using the Expo Go App on an iPhone 7 (to test on low-end devices). I monitored its ratings while the app actively performed operations such as fetching data from remote sources, storing or manipulation of data and rendering of components. Its performance rating on the UI thread was consistently within 60 FPS, the lowest it dropped to after initial mount was 57 FPS. The JS thread was however inconsistent in its ratings. During basic actions such as scrolling through the list content, it consistently reported a rating around 60FPS. The rating however dropped to as low as 30 FPS during rendering of content, manipulation of data, navigation and other JS thread related activities. I was however unable to get any conclusive evidence that indicates the performance lag was indeed caused by the NestedLists implementation.

One other major limitation that flawed NestedLists is its lack of virtualization. Virtualization is an important feature of a performant list as it optimizes resources to maximize performance while rendering list content as necessary. My incomplete understanding of the behind the scenes logic or the optimal approach to designing such a feature is why I ignored it during the implementation of NestedLists.

Conclusion

I enjoyed every bit of trying to recreate one of React Native’s core components as it helped enhance my understanding of how React Native is able to wield the wonderful weapon of deploying applications for multiple platforms without breaking a sweat, well, maybe just a little, okay a lot of sweat 💀. The purpose of this writeup is to open myself to feedback, I am curious about what fellow React Native warriors think about my implementation. Was this a pointless venture with rewards that could have been sowed through less excruciating means? Should I even be trying to reinvent the wheels?

I have linked the repo to my Instagram profile screen implementation, it includes the source code for NestedLists.

Please comment your feedback on what or how I could have done better.