DEV Community: Mohamed Eltohamy

My iPhone 16 Pro Stuttered but the S24 Felt Smoother: A React Native Skia Hunt

Mohamed Eltohamy — Tue, 14 Jul 2026 14:13:41 +0000

On paper, an iPhone 16 Pro should never stutter rendering 192 circles with React Native Skia. But my screen was stuttering, and the FPS counter said 80

While testing the animation, I felt a small jitter. I ignored it because it was running in the simulator. Then I ran it on my iPhone 16 Pro, and there it was again: the stutter.

I ran it on both my iPhone 16 Pro and Samsung S24 side by side, and the S24 showed nothing or at least I didn't catch it, but the iPhone was consistently stuttering in the transition phase of the animation.

// Detect dark theme var iframe = document.getElementById('tweet-2055622804083708159-542'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2055622804083708159&theme=dark" }

I got the inspiration from something I saw on Minsang Choi's X and Siri border glow.

Picture 192 balls: 128 on the border and 64 oscillating, moving like one gooey metaball blob, merging, and separating as the user interacts with the app.

So I thought of my stack:

Expo, of course
Skia RuntimeEffect shader
Reanimated 4 worklets and SharedValues

First a quick metric guide as we're gonna repeat this all over the post

Metric What it means How to read it here

FPS Average frames rendered per second Good first signal, but it can hide visible stutter

Frame budget Time available to finish one frame 120Hz = 8.33ms, 60Hz = 16.7ms

Missed frame % Share of frames that missed the target budget Better than average FPS for spotting stutter

p50 / p90 / p99 Median / slower-end / worst-end timings Shows whether the problem affects most frames or only the tail

Encoder time CPU time spent submitting work to Metal Useful, but it does not prove shader execution was cheap

JS thread vs UI thread React Native JS work vs animation/worklet-side work JS can be idle while UI-thread worklets still cause frame drops

Main rule: average FPS tells you speed; frame timing tells you rhythm.

Metric	What it means	How to read it here
FPS	Average frames rendered per second	Good first signal, but it can hide visible stutter
Frame budget	Time available to finish one frame	`120Hz = 8.33ms`, `60Hz = 16.7ms`
Missed frame %	Share of frames that missed the target budget	Better than average FPS for spotting stutter
p50 / p90 / p99	Median / slower-end / worst-end timings	Shows whether the problem affects most frames or only the tail
Encoder time	CPU time spent submitting work to Metal	Useful, but it does not prove shader execution was cheap
JS thread vs UI thread	React Native JS work vs animation/worklet-side work	JS can be idle while UI-thread worklets still cause frame drops

The GPU Is the Obvious Suspect

It must be the GPU
So I started as always with the performance monitor.
The S24 averaged 110fps and dropped down to ~104fps on transition. However, the iPhone showed ~39fps on the UI counter, while the JS stayed at 60fps.

Hindsight:
The reading showed clean JS thread performance on iOS which should've hinted where the problem was.

As these results showed what I was experiencing, but nothing more, I needed another way to really find out what went wrong. I tried the inspector, but I couldn't get valuable GPU data from it.
I needed to go deeper.
That's when I looked into native profiling as this was the first time I had profiled the GPU beyond the performance monitor and custom logging code.

As I was mostly concerned with iOS, the tool for the job was Instruments. I had never used it before so I needed some help. Fortunately, the tool was simple to understand and it's well-integrated in the iOS ecosystem.

With a fresh release build, on device, I used the Metal System Trace template. I started recording for ~10 seconds with steady triggers. Here's the result:

Encoder time was nearly empty. Microsecond submits, apart from one frame-1 spike (the shader compile).

CPU usage was busy. Something is working hard every frame. But what?

I didn't understand much 😭 apart from some spikes with orange and some long operations. Two tracks stood out enough to extract data from; see the callouts above. The rest of the trace was noise to
me. (It wasn't. But that comes later.)

So instead of trusting the chart, I extracted data.

Encoder p50:    140 µs
Encoder p99:    621 µs
Encoder max:    15,790 µs  ← only frame 1 (shader compile)
> 1ms:         1          (just the first frame)

Still 42% of frames missed the 16.7ms budget by ~1ms 👀.
(Yes, 16.7ms, not the 8.33ms from the metric guide. The animation was heavy enough that the display had already dropped out of its 120Hz cadence. Why that happens comes later.)

One caveat:

I could not get reliable shader execution timing from Instruments, so this did not fully clear the GPU. But the measured data was pointing away from Metal submit and toward something happening earlier in the frame.

The frame was late at ~17ms, but the Metal submit was a fraction of that at 0.14ms.

Now the question is, what was happening upstream before Skia submitted the frame?

The Journey Upstream

The GPU handoff is clean, who's eating the 17ms?

Testing the Upstream Theory

The encoder submit was tiny, so the cost wasn't at the CPU → GPU data handoff. The steady 17ms frame intervals did not look like a random GPU spike either.

That made the upstream theory worth exploring.

So I added the Time Profiler to check what was happening before Skia submitted the frame.

Adding Time Profiler

I hoped this would help answer the question of: which code is running during those 17ms?

Total CPU samples:    3,099 ms over 10 seconds
Main Thread:          2,234 ms  (72.1%)
JavaScript thread:       18 ms  (0.6%)   ← idle
AGX / Metal driver:   single-digit samples each

This shows 3 unambiguous things:

Metal driver is barely doing any work.
JS thread is idle.
UI (Main Thread) (where the worklet lives) is doing most of the work.

In this setup the worklet runs on the UI runtime, which shows up as Main Thread work on iOS, and that's why the React Native JS thread is idle while the animation was doing heavy work.

And there it was: the worklet looked guilty. But could it be the calculations, or something else entirely?

The Worklet Was the Wall

What made the worklet slow? Was it the math or the way I wrote it

Now that I had narrowed down the symptom to the Main Thread, I dug in deeper and traced its call tree.

Two culprits surfaced from leaf functions, putComputedWithReceiver_RJS and malloc/free (_xzm_xzone_malloc_tiny). I had to search what they were as I was unfamiliar with Hermes lower-level functions.

In plain English, the profiler was pointing at two things:

generic indexed writes: buffer[i] = value

short-lived allocations: creating and discarding a fresh array every frame

putComputedWithReceiver_RJS: Hermes' bytecode handler for a computed property write, obj[key] = value where the key is computed, like an array index. It's the slow path because Hermes can't use a fixed object shape; it has to do a generic lookup per write.

In the code: the worklet's buffer[i] = x, buffer[i + 1] = y, … loops over 128 mostly static balls and 64 oscillating ones.
At 4 indexed writes per ball, that came to ~768 writes per frame at 192 balls. That loop is what lit this function up.

malloc/free (_xzm_xzone_malloc_tiny): the iOS allocator's fast path for tiny allocations.
Seeing it hot suggested is allocating short-lived objects that the GC deallocates right away.

In our code: the new Array(MAX_META_BALLS * 4).fill(0) allocated a fresh buffer and discarded it every frame, 120×/sec. That's the allocation + GC churn this pair represents.

Both costs came from useFrameCallback(), the Reanimated callback I was using to prepare the animation state every frame:

Allocate a fresh buffer
Compute ball positions
Write values into the buffer

So the worklet was not losing time because the ball position math was complex. It was losing time because of how I was rebuilding and rewriting a large JS array every frame.

At this point, the goal looked obvious: remove the allocation, reduce the indexed writes, and stop rebuilding the buffer every frame.

I was happy. I thought I had found the bottleneck.

I hadn’t.

The False Victory

Double-buffer arrays, 80fps → 104fps

So I had two issues to fix:

allocation churn: allocating a new buffer every frame.
indexed writes: writing many computed indexes per frame, which hit Hermes’ generic property-write path.

Allocation churn

First, I tackled the allocation churn.

The solution had two parts:

No new Array(...) allocation and no .fill(0) on every frame, which ballooned the memory and pressured the GC.
Allocate two reusable arrays once at module scope, fill in place, and flip which one you write each frame.

Why two buffers, not one?

Because Reanimated needs a new reference to propagate the update. If I reused one array and assigned ballBuffer.value = buffer every frame, the reference stayed the same and Skia could miss the change.

Two buffers fixed both issues:

different reference → Reanimated propagates the updates.
different write/read buffer → safer handoff between reading and writing.

Result:

This fix improved frame performance from 80fps → 104fps and reduced missed frames from 42% → 15%. A big, real, measured jump.

It was a real win, and it made me confident I was on the right track, which was a morale boost. But it didn't directly address the indexed-write cost.

Why call it false victory?

104 wasn't 120, and I'd convinced myself I knew why. Both of those would come back to bite me.

The Relapse at 128 Balls

64 balls clean, 128 balls janky. Hermes again... right?

So after that "victory", I reduced the ball count from 128 border and 64 oscillating to 32 balls each.
I also played around with the Metaball knobs to get the desired look, however, I was more concerned with the performance.

// Detect dark theme var iframe = document.getElementById('tweet-2057233292941025410-684'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2057233292941025410&theme=dark" }

The performance was the best so far, holding at ~122fps→123fps with ~0.1% missed frames.

This was perfect, however, I couldn't get the look I wanted.
So I increased the ball counts to 64 border and 64 oscillating and the stutter came back.

Smaller this time but still real.

So here's what we have so far, after the double-buffer fix:

Ball Count	Avg. FPS	Miss %
64 (32 + 32)	~122–123fps	~0.1%
128 (64 + 64)	~115fps	~1.5%

I thought, Hermes again, right!

The numbers don't lie: adding more balls meant more writes, which dropped the frames.

It wasn't that one-to-one though, and that's what I found out.

The reflex "Hermes again" was untested.

So I measured the write loop directly.

I logged inside the worklet itself at the write loop, logging write-ms every 60 frames as a baseline and on every dropped frame, in a release build.

The results were shocking with writes maxing at 0.90ms, even the dropped frames weren't slow they were even faster. That was the smoking gun 🔫. If the write loop finishes under 1ms, even on dropped frames, then the bottleneck must be something downstream.

One Variable Was Actually Three

"More balls" was never one knob

I kept trying ball counts, yet something felt off.

I even reduced the number of writes by making some passed values static, like the ball radius.

Nothing changed.

It must be something else that I was missing, maybe I was looking in the wrong place.

I thought I was testing one variable:

more balls

But I was actually changing three things at once.

Variable	What changed	Why it mattered
JS writes	More balls meant more buffer writes	More Hermes indexed writes
Shader loop work	More balls meant more metaball evaluations per pixel	More SDF work inside the fragment shader
Pixel count	Supersampling increased the rendered pixel area	The shader ran over many more fragments

The first one was obvious because I had just fixed the array allocation problem.

The second one was easier to miss.

Inside the shader implementation, each pixel loops over the active balls. So increasing the ball count does not just add more data to pass from the worklet. It also adds more work for every pixel the shader touches.

However, the third variable was the real trap: supersampling.

I use supersampling to keep shaders clean and crisp. The idea is simple: render the shader into an offscreen layer at a higher scale, then downsample it back to the logical size for antialiasing.

In code, it looks like this:

// ss = device pixels × the supersample factor.
const ss = PixelRatio.get() * SUPERSAMPLE_SCALE;
...
  // outer scale(1/ss) downsamples the ss× layer back to logical size (the AA)
  <Group transform={[{ scale: 1 / ss }]}>
    {/* inner scale(ss) renders the metaball field at ss× density (the cost) */}
    <Group
      transform={[{ scale: ss }]}
      layer={
        <Paint>
          <RuntimeShader .../>
        </Paint>
...

That looks harmless, but the cost is quadratic in scale.

Because scaling affects both the width and the height, the pixel count gets squared: pixel cost ≈ ss².

So on a 3× device, even SUPERSAMPLE_SCALE = 1 means the shader can run over roughly 9× as many pixels.

And every one of those pixels loops over the active balls.

So the cost wasn't the ball count itself.

It was closer to:
active_balls × shaded pixels

And supersampling was the hidden multiplier:

(PixelRatio × SUPERSAMPLE_SCALE)²

The full formula comes next.

That changed the whole investigation.

The relapse at 128 balls was not clean proof that Hermes writes were still the bottleneck.

It was a mixed test, with hidden variables I was yet to discover.

I had increased the writes, increased the shader loop work, and increased the amount of fragment work all at the same time.

The real cost model was bigger than I thought.

The Real Cost Model

Formula

active_balls × logical_resolution × (PixelRatio × SUPERSAMPLE_SCALE)²

This was the formula that I should've used from the start, as it separates the real costs:

Term	Meaning
`active_balls`	how many balls the shader evaluates
`logical_resolution`	how many logical pixels the effect covers
`(PixelRatio × SUPERSAMPLE_SCALE)²`	how much supersampling multiplies the shader calculation

The 128-Ball Example

27 billion ball evaluations per second

Let's apply the formula to the 128 balls case:

The exact number matters less than the scale. This was not a perfect GPU cost estimate, it was a way to see the order of magnitude I was asking the shader to handle.

active_balls = 128
logical_resolution ≈ 402 × 874 = 351,348
(PixelRatio × SUPERSAMPLE_SCALE)² = (3 × 0.75)² ≈ 5.06

So the estimated work per frame was:
128 × (351,348 × (3 × 0.75)²) ≈ 227.7 million estimated ball evaluations per frame
At 120fps:
227.7 million × 120 ≈ 27.3 billion ball evaluations per second

That was the number that I should've been looking at from the start.

Not just how many balls I had or how many values I wrote.

The real cost was how many times the shader had to evaluate those balls across the rendered pixels.

Proving The Formula

The formula was still just a theory. To test it, I changed exactly one variable and watched the frame time follow. Same 128 balls, same buffer writes, same shader, changing nothing but SUPERSAMPLE_SCALE:

Config	Rendered pixels	Avg. FPS	Miss %
128 @ 0.75 (ss² ≈ 5)	~5× logical	~115fps	~1.5%
128 @ logical (ss² = 1)	1× logical	~124fps	~0%

Same balls. Same writes. Same shader. The only thing that changed was how many pixels the shader ran over, and the stutter tracked it exactly. Drop the pixel count and the jank vanished; the frame held a clean 120fps.

That was the confirmation. Ball count and writes were not the whole story. After the double-buffer fix, the dominant cost was fragment shader work: evaluating those balls across every rendered pixel.

That made the ~115fps result much less mysterious.

The frame did not need one huge bottleneck to miss. It only needed a small amount of extra fragment work repeated hundreds of millions of times.

After the double-buffer fix, Hermes was no longer the main suspect. The bigger cost was now fragment work.

The ProMotion Twist

107fps that felt like 60

Comparable fill load, yet the iPhone 16 Pro felt worse than the Samsung S24.

Not because the average FPS was dramatically lower. At 0.75, the iPhone averaged ~107fps, while the S24 averaged ~115fps.

Close. But the iPhone missed 11.2% of its frames against the S24's 1.5%, and those misses were far more visible.

The key was ProMotion. On supported iPhones, the display can dynamically vary its refresh rate up to 120Hz. That means the target frame budget is tiny:

120Hz = 8.33ms per frame

ProMotion dynamically selects from supported presentation rates. But for this animation, the frame-time histogram showed two dominant cadences: frames near the 8.33ms target and a large pile-up around 16.7ms, the length of a 60Hz frame.

So a modest overshoot could read as a 2× frame-rate collapse, not gentle degradation.

At 0.75 supersample, the same ~5× fill from the last section, 342 frames grouped around ~16.7ms, versus just 3 frames at logical resolution.

That was the twist.

And it's why 107fps was misleading. It looked like the frame pacing was flickering between frames near the 120Hz cadence and frames lasting roughly 16.7ms.

Most frames made the 120Hz deadline.

But enough frames missed. And on an adaptive panel each miss could become a frame displayed for roughly twice as long. Those misses became visible as rhythm changes: smooth, smooth, smooth, hitch, hence the stutter.

The S24 produced far fewer missed frames under the same configuration: 1.5% versus 11.2%. My measurements establish that difference, but not whether it came from Android’s presentation policy, GPU throughput, driver behavior, or another platform-specific factor.

Know your platform’s failure mode: on a high-refresh display, average FPS can hide the problem. Frame-time distribution and missed-frame percentage reveal the rhythm your eyes actually see.

What Did Not Help

Every fix that made sense and changed nothing

Reducing Only the Worklet Writes

Tackling this was my first reflex after falsely diagnosing it as an upstream issue.

Freezing static values and experimenting with typed arrays may have reduced or changed the write path, while per-ball SharedValues changed the data flow entirely.

None of them improved frame time because the double-buffer had already made the path cheap enough.

Treating Ball Count as the Whole Cost

"More balls = more cost" was one part of the equation, actually one of three. The real driver was active_balls × logical_resolution × supersampling², which is why the same 128 balls could be clean at logical resolution and janky at 0.75 of the device PixelRatio.

Assuming the GPU Was Cleared Too Early

Those microsecond Metal-submit times from the start? They only cleared the CPU→GPU handoff, never the GPU's actual work. Instruments could show me the GPU was busy, it just couldn't tell me how busy, or with what. So fragment fill stayed unmeasured the entire time, and turned out to be the dominant hidden cost.

Look again at that first Instruments trace: an empty encoder track sitting directly on top of a GPU track that never goes quiet. The story was right there. I just couldn't read it yet.

What Actually Helped

Two buffers, fewer pixels, and a histogram

Reusing the Buffers

The double-buffer approach was one of the best solutions. It introduced a more robust way of handling the data, fixed the allocation churn, and pushed the investigation downstream, where most of the remaining frame cost lived.

Two module-scope arrays, filled in place and flipped each frame, killed the per-frame allocation and its GC churn. That took me from 80fps to 104fps, while missed frames dropped from 42% to 15%.

This was the one CPU-side change that genuinely mattered, back before fill became the wall.

Reducing the Per Pixel Evaluations

This was the MVP of all the solutions.

Pixel density was the major cost delaying frames past the 8.33ms budget, and it scaled with the square of the device PixelRatio (ss²), so it climbed fast.

It had two knobs:

SUPERSAMPLE_SCALE: dropping from 0.75 to logical resolution cut the fill ~5× (227.7M → 45M ball evaluations per frame). On the iPhone 16 Pro that took it from 107 → 119fps, 11.2% → 0.3% missed, and the 16.7ms pile-up collapsed from 342 → 3 frames. On the S24: 115 → 124fps, 1.5% → 0%.
Active balls (128 → 64): the cost is a product active_balls × rendered_pixels. So I could attack it from the other side too.
Halving the active count took it from 115fps and 1.5% missed frames → 122–123fps and 0.1% missed frames, for the same reason: fewer balls means fewer evaluations at every pixel.

Both knobs trade quality for frames. Breaking that trade-off means going into the shader itself, that's at the end.

Measuring Frame-Time Distribution

On paper, the two runs weren't far apart: 107fps vs 119fps.

The distribution told the real story:

p90: 17.02ms versus 8.81ms
Missed frames: 11.2% versus 0.3%

That's the same pile-up ProMotion made visible, and without it, I
would've stayed lost in the sauce, chasing an average that never
represented a stable cadence to begin with.

Separating JS Cost From Fragment Cost

Every breakthrough came from measuring the two halves independently.

First, I timed the writes inside the worklet. Then I held the ball count constant while only changing the supersampling level (1, 0.75, etc.).

The in-worklet timing largely ruled out the write loop as the cause of the dropped frames:

0.34ms median
0.90ms max
0 of 157 dropped frames spent more than 2ms writing

The writes were actually faster on the frames that stuttered.

Then, with the ball count fixed, changing only the pixel count moved performance from 107fps to 119fps.

That strongly implicated the fragment work.

This separation revealed where the elusive dominant cost lived.

Takeaway

The bug was never where I first looked

The Fix That Works Can Become the Bias That Blinds You

Twice I was confidently wrong, and both times it was the previous win talking.

First: "it's the GPU".

It was the worklet.

Then, after the double-buffer fix: "it's Hermes again".

It was fragment fill.

The model that won last round is the first suspect you should distrust this round.

That bias felt reasonable because the previous bottleneck had been real. But once I had reduced it, continuing to blame it stopped being evidence and became habit.

Isolate Your Variables Before You Trust the Result

The whole cliff hid behind three knobs that moved together:

worklet writes
active-ball shader iterations
rendered pixels from supersampling

"More balls" looked like one variable.

It was actually three.

Nothing made sense until I pinned two and moved one at a time.

Each Phase Needs Its Own Instrument

FPS said frames were late.

Metal trace cleared the submit.

Time Profiler found the thread, then the function.

But to understand the write loop cost, the most reliable measurement came from timing it inside the worklet itself.

Each tool answered only one part of the question.

Because Instruments was Apple’s native profiler, I wanted to treat it as the single source of truth. But even a native tool is only authoritative about what it can actually measure.

Know Your Platform’s Failure Mode

Under comparable settings, the iPhone produced many more missed frames than the S24, and those misses were more visible.

Average FPS hid the nature of the failure.

On a high-refresh display, the frame-time distribution and missed-frame percentage map closely to the stutter your eyes actually see.

The bug was never where I first looked.

The method is what got me there.

What's Next: Attacking the Shader Itself

The knobs I turned, fewer balls, less supersampling bought back
the frames by trading away quality. That works, but it treats the
symptom.

The cost model says the real enemy is the product itself:
active_balls × rendered_pixels. Every ball, evaluated at every
pixel, every frame. As long as that multiplication stands, quality
and performance stay locked in a trade-off.

So the next investigation goes into the shader itself: can that
product be broken? I'm experimenting with a few approaches, and
early signs say yes, but I've been confidently wrong twice in this
post already, so I'll let the measurements speak in part two.

Final Debugging Checklist

This is the checklist I wish I had before starting. Use it if you're working on something similar.

Setup

[ ] Test on a real device, in a release build. Simulators lie.
[ ] Commit each experiment with the config and numbers. Reconstructing performance results later is painful.

Measure before changing anything

[ ] Record a baseline first.
[ ] Do not trust average FPS alone. Capture frame-time distribution and missed-frame %. My 107fps average hid a 16.7ms pile-up.

Locate the phase

[ ] Check JS thread vs UI thread first. Clean JS + busy UI usually means worklet or native-side work.
[ ] Tiny GPU submit time does not clear the GPU. It only clears the CPU → GPU handoff.
[ ] Use Time Profiler to find hot leaf functions. Look up unfamiliar ones before building a theory.

If the CPU side is hot

[ ] Kill per-frame allocations. Pre-allocate buffers and reuse them.
[ ] Double-buffer when the reactive system needs a new reference to propagate updates.
[ ] Verify with in-worklet timing. If writes stay under 1ms on dropped frames, stop optimizing that path.

If frame cost scales with pixels

[ ] Write the cost model before guessing: work_per_pixel × rendered_pixels.
[ ] Treat supersampling carefully. Scaling width and height means pixel cost grows with ss².
[ ] Change one variable at a time. “More balls” was not one variable, it moved writes, shader loop work, and pixel count together.
[ ] If fill is the wall and you can't trade more quality, the cost structure itself is the target, that usually means shader-level changes.

If the device has a high-refresh display

[ ] Check the 8.33ms boundary, not just the average FPS.
[ ] On ProMotion, a small miss past the 120Hz window can present like a 16.7ms frame, a visible 2× hitch.

Bias check

[ ] After every fix, re-measure from scratch.
[ ] The last bottleneck you found is the first suspect to distrust.

Fibonacci grid in React

Mohamed Eltohamy — Fri, 19 Jun 2026 10:04:22 +0000

Goal

I want to create a Fibonacci grid pattern component in React that can the user can use and add elements to in any orientation.

React Component ⚛️

I started by creating a React Component called /code FibonacciGrid, and then added a couple of states.

Orientation is an enum that is either horizontal or vertical.
nBoxes for specifying the number of boxes/elements in the grid (It should be a multiple of 3)
elementResolution which holds the width and height of the grid specified by the user.

Grid vs Flex Layouts

Grid layout was my initial choice when I got started with this as it’s called FibonacciGrid after all and a grid looks like it’ll be the obvious choice right? … well wrong because for the design that I made, I only needed to worry about 3 elements (Probably could’ve been done easily by grid but I already did something like it with flex and I love ❤️ flex. So flex is a go; here’s the orientation that I’m aiming for:

I’m going to nest this layout in itself as you can see here:

You can see how it keeps nesting a new FibView, yeah I’m calling that now. Getting back to what's at hand, if the user sets the number of views/boxes to more than 3 then we’ll have to nest another view and repeat the process.

Design

I made this

Orientation Wars

Making the view have one behavior is simple enough, but now I need to make it dynamic.

I set up a lot of variables and this function changes the variables on orientation change….

And it worked, for the horizontal view, but not for the Vertical (as expected 🤪).

Here’s how it looked:

and that's even after I applied a little bit of React Wizardry.

if so then add it to the bottom of the flex row direction, ah yeah I did that too, now I change the flex-direction depending on the orientation.

Need to fix the vertical orientation issue

OMG!!! So I was adding the 1 view to the same flex that contains the other two views, so I ended up with the 3 views with a 37% height and that was the issue.

Reverse/Flip Orientations

Vertical reverse and horizontal reverse,

The end result should be like the one on the figure on the left, after changing a few things I set up the view to change the size to a fixed width and height based on its orientation.

For some reason, I got the following figures on the right, not the same but close. Now starts the game of trial and error.

HorizontalReverse

That was an easy one, I just needed to add one line to the condition that adds the large view to the end.

{(orientation === OrientationEnum.vertical ||
        orientation === OrientationEnum.horizontalReverse) && (
        <div

onto the next one…

VerticalReverse

Now

Orientation Expansion

So as I was figuring out what to do I noticed that I missed a couple of orientations 4 to be exact. I was contemplating whether to implement them now or not as they’ll add an extra level of complexity, knowing me I just had to do it. This btw was a side project of a side project soooooo… let’s get into it.

I went and added the extra orientations and worked out a nifty new way to figure it all out.

Flip (the nifty way)

Now it’s getting complicated, but don’t worry I think I figured a way to simplify things.
I added a new variable flip which will just vertically flip all of the original 4 orientations, you can ask me why don’t I make flip-horizontal and flip-vertical, and to that, I say shhhh, not now but that is the future plan. (Something for another day).

I leave this here as there is something more important that I need to do.

Important Change

As of now most of the views are working well, I thought there should be some style added to them.

I went and downloaded a couple of beautiful images from Unsplash from these amazing artists, check their work in the links below.

Photos by Freguesia de Estrela on Unsplash

Photo by Milad Fakurian on Unsplash

Photo by Daniel J. SchwarzHire on

Photo by NEOM on Unsplash

Photo by Marek Piwnicki on Unsplash

OK, let’s address the elephant in the room (🦣 me) not you 🐘 yeah you, seriously though we need to now add children to the FibView. I’m now faced with a choice either to implement adding children to the view which is the whole point of this or add the images in the fibview itself, hmmmm.. Well as you know by now I usually take the harder route and give up midway, but that’s what what we’re gonna do right now.

So as I never did this before I jumped into React’s docs and I think it’s gonna be something like this

<FibView> 
    <img src="1.png"></img>
    <img src="2.png"></img>
    <img src="3.png"></img>
    <img src="4.png"></img>
    <img src="5.png"></img>
</FibView>

Then in the view we’ll get the children just like what we do with ContextProviders, so something like this

SomeContextProvider(props: PropsWithChildren) {
...
    {props.children}
...
}

And after a little digging, it is actually the way, you gotta love modular systems.

I added the children to my view like so

export default function FibonacciView({
  _orientation, children
}: PropsWithChildren<FibonacciViewProps>)

However, now I have an issue, I need to add the children to different parts of the view, then I need to use an array of children which thankfully react got us covered on that by using 'Children.toArray(children)` .

After that, I styled the images to fill the view they’re assigned to, and then onto the assigning children to their views, then recursion which I’m trying not to think about right now. 🙆‍♂️

The above are the 4 main orientations, I got distracted by this and didn’t do the flip. I should also have a gap setup for the view and restrict the number of children based on the total view height, but these are problems for another day and hopefully 🙏 I’ll be adding them as the days go by.

Back to Flip or BackFlip

I’m sorry 🥲

Flip horizontal

Flip horizontal Reverse

I had to fix the Horizontal reverse as it was actually flip in the original view. To be honest, the code is getting more complicated, but my concern is not the complexity, it’s the readability of it and for that, I’m going to create a new /(Link to section)structure to further modularize the views.

Flip Vertical

Now I’m getting the hang of it, Vertical flip works like a charm.

Flex is acting up

I noticed a weird behavior

Flip Vertical Reverse

I’m so glad that everything is coming to fruition, yet I still don’t like the way it’s coded, I need to figure out a way to make it more simple to understand and use.

Aside

I’m thinking of designating different parts of the view as zones and then making different views then assigning them to the appropriate zone, I still don’t know. Please let me know your thoughts

Weird Typescript issue

{((orientation === OrientationEnum.horizontal && flip) || orientation === OrientationEnum.horizontal ||

OMGGGG

I just realized that I need to write the component in Javascript.

Putting it outThere

I asked around to see how to create an npm react component for everyone to use and luckily I got a great answer from one pf the communities about where to look, and it was Vite.

After some research and checking the reviews I found that the Vite solution might have some issues with SSR (Server Side Rendering) and embedding CSS on the server like in NextJs, now I needed a faster more efficient way.

Using Tsup

Onto the Recursion

I figured I had to finish the recursion before I bundle it.

I’m currently trying to figure out a way that will fix the sizing as I want to dynamically set the size of the fibView and then pass a % size recursively for the views

Refactoring...

I had to refactor a couple of states within the fibView:

const [orientation, setOrientation] = useState<OrientationEnum>(_orientation);

And now I’m using a prop to set it from the parent to be able to dynamically change it.

const [elementResolution, setElementResolution] = useState<ViewResolution>( getViewResolution(orientation, _viewResolution) );

This also was another change for the same reason as it’ll help in the recursive step to be able to dynamically change the size and orientation of the view. Maybe I’ll revert to the original, but these states didn’t make sense as I just set them up and didn’t change them after that.

export type FibonacciViewProps = { orientation: OrientationEnum; _flip?: boolean; _changeOrientation?: () => void _viewResolution: ViewResolution; };

This is the updated view properties… for now.

Hotfix for height

Height ap

Back to the recursion

I’ll check if we have more than 3 views I’ll have to create a child FibView recursively.
So for example If I add 8 views like so

<FibView> <img src="1.png"></img> <img src="2.png"></img> <img src="3.png"></img> <img src="4.png"></img> <img src="5.png"></img> <img src="6.png"></img> <img src="7.png"></img> <img src="8.png"></img> </FibView>

2 should be displayed on the biggest views and then the remaining 6 images should be passed to the next FibView that's inside the smallest view which will display 2 images and have another FibView with the rest and so on.

Now that I’m thinking about it I don’t know if this is the best way to do it

HMMMMMMM

Now that I have gotten myself into this rabbit hole, I need to figure out an algorithm to calculate the next fibView in the recursion. I’ll take the horizontal view as a test case

Take a step back (Working out the sizes of the views)

Apparently, a parent’s height needs to be determined in order for the child to use percentages, so now I’ll refactor the code in a way to retrieve the actual height of an element and cascade the effect for all of the children.

After a lot of refactoring, I managed to make it work somehow.
But now I have a better idea, instead of supplying the width and height ///