DEV Community: MZ

editMode environment variable

MZ — Sat, 31 Jan 2026 14:55:42 +0000

@Environment(\.editMode) var editMode is more of a binding rather than a value. A lot of tutorials touch on it as if it already has a value but it is actually a binding variable, meaning someone has to give it a value.

The usual use case is usually when dealing with Lists and EditButton(). In this case, however, there is no explicit declaration of @Environment(\.editMode) var editMode anywhere in the code because List provides a value to editMode internally so we dont really see it happening. So now, we can safely attribute each element to a function.

Namely:
1) EditButton() simply toggles editMode, the environment variable, when the user taps on it
2) List sees this change (because it tracks editMode) and turns on edit mode. It switches the text on the edit button from "Edit" to "Done" and surfaces the usual UI for deleting entries.

Even though editMode was never declared explicitly, it is still the single source of truth.

That's the usual use case. However, if you want manual control, there is another way.

@Environment(\.editMode) var editMode as a binding suggests that it would be declared in a child view. So, how do we give it value? We do up our own "edit mode" variable in the parent view.

This could look like

@State private var editMode: EditMode = .inactive

This variable is being declared as of type EditMode and of value .inactive. If you search up the documentation for @Environment(\.editMode) var editMode, you will find that editMode has 3 enum values, .inactive being one of them.

Now that we have our own state variable, we actually need to inject it into view. Notice the .environment() modifiers?

NavigationStack {
    VStack(spacing: 16) {

        if editMode == .active { // 4) this follows our own state
            Text("I appear only in Edit Mode")
                .padding()
                .background(.yellow)
        }

        Text("Always visible")
        EditButton() // 3) this toggles swiftui's editMode env var, not our own state variable
        Button("tap me for second view") {
            isShowing.toggle()
        }
    }
    .environment(\.editMode, $editMode) // 2) feed and bind your own state into swiftui's env var
    .fullScreenCover(isPresented: $isShowing) {
        SecondContentView()
            .environment(\.editMode, $editMode) // 5) feed and bind your own state into swiftui's env var for the second view
    }
}

.environment(\.editMode, $editMode) means I want to bind the value of my own self-declared editMode into the environment variable binding of \.editMode.

Also, notice how we have to keep injecting our state into our view and onto the child view? That's expected and normal behaviour.

This then translates to our second view:

struct SecondContentView: View {

    // 6) @Environment introduced as a bind here
    @Environment(\.editMode) var editMode

    var body: some View {
        NavigationStack {
            VStack(spacing: 16) {

                if editMode?.wrappedValue.isEditing == true { // 7) this follows the actual environment API
                    Text("I appear only in Edit Mode")
                        .padding()
                        .background(.yellow)
                }
            }
        }
    }
}

This code now coincides nicely with how editMode is often portrayed as. Now, it is a binding variable and it has value.

We also have a different if statement now because we are actually using the API now, not our own state variable.

if editMode?.wrappedValue.isEditing == true { // 7) this follows the actual environment API

The code should work now if you run it. The second view will follow if you toggle editMode from your first view.

Reducers

MZ — Wed, 14 Jan 2026 16:44:04 +0000

We usually use reducers when we start having a bunch of setState() growing all over the codebase. It is also a way to manage the logic and put them into one place.

Consider the code below.

import { useReducer, useState } from 'react';

const App = () => {

  const [tasks, setTasks] = [
    {id: 0, text: 'Visit Museum', done: true},
    {id: 1, text: 'Watch a puppet show', done: false},
    {id: 2, text: 'Lennon Wall pic', done: false},
  ]

  const [inputText, setInputText] = useState('')

  const onInputTextChange = (e) => {
    setInputText(e.target.value)
  }

  const handleTaskAdd = () => {
    // setting state here
    setTasks(
      [
        ...tasks,
        {id: tasks.length, text: inputText, done: false}
      ]
    )

    setInputText('')
  }

  const handleTaskDelete = (taskId) => {
    // setting state here
    setTasks(tasks.filter(task => task.id !== taskId))
  }

  return (
    <div>
      <input type="text" value={inputText} onChange={onInputTextChange} />
      <button onClick={handleTaskAdd}>add task</button>

      <ul>
        {tasks.map(task => {
          return(
            <div key={task.id}>
              <p>{task.text}</p>
              <button onClick={() => handleTaskDelete(task.id)}>Delete</button>
            </div>
          )
        })}
      </ul>
    </div>
  )
}

As you can see, there are some logic attached to the setState() portions of the code. This looks uncluttered and unmessy now, but when the codebase becomes larger, this is going to be an issue.

The main idea behind reducers is to, well, reduce. We essentially separate out the logic and state management into a part on its own.

The reducer holds and/or accepts 2 things.

tasks is the current state
action is the object relayed from the dispatch call.

As you can see in the code below, action carries several things, what type of change it is and the payload itself (or the content of said change).

const taskReducer = (tasks, action) => {
  switch (action.type) {
      case 'add': {
        const arr = [
          ...tasks,
          {id: tasks.length, text: action.text, done: false}
        ]
        return arr
      }
      case 'delete': {
        const arr = tasks.filter(task => task.id !== action.taskId)
        return arr
      }
      default: {
        throw Error(`Unknown error: ${action.type}`)
      }
  }
}

Reducers are a mindset shift. Instead of setting states, we are sending out "actions".

In reducers, we mostly interact with the actions object.

we check what type of change it is
we deal with the logic and return the new state (we are utilising the tasks state in the logic here)

So, we're done with the main logic. How do we utilise it?

In the file that we would like to use the reducer in, import useReducer.

import { useReducer, useState } from 'react';

In the component that you are planning to use reducers in, do this.

const initialTasks = [
  {id: 0, text: 'Visit Museum', done: true},
  {id: 1, text: 'Watch a puppet show', done: false},
  {id: 2, text: 'Lennon Wall pic', done: false},
]

const [tasks, dispatch] = useReducer(taskReducer, initialTasks)

Now, you have the initial data, initialTasks.

useReducer takes in the reducer itself and the initial state to hold and it returns [tasks, dispatch]. Notice something familiar?

we just turned

const [tasks, setTasks] = [
  {id: 0, text: 'Visit Museum', done: true},
  {id: 1, text: 'Watch a puppet show', done: false},
  {id: 2, text: 'Lennon Wall pic', done: false},
]

into

const [tasks, dispatch] = useReducer(taskReducer, initialTasks)

Same mechanics.

Now, instead of:

dealing with the logic in the same file or line of code, you outsource it to the reducer
setting tasks using setTasks, you call dispatch

This is the updated code.

import { useReducer, useState } from 'react';

const App = () => {

  const initialTasks = [
    {id: 0, text: 'Visit Museum', done: true},
    {id: 1, text: 'Watch a puppet show', done: false},
    {id: 2, text: 'Lennon Wall pic', done: false},
  ]

  const [tasks, dispatch] = useReducer(taskReducer, initialTasks)

  const [inputText, setInputText] = useState('')

  const onInputTextChange = (e) => {
    setInputText(e.target.value)
  }

  const handleTaskAdd = () => {
    // copy array and append from there
    // setTasks(
    //   [
    //     ...tasks,
    //     {id: tasks.length, text: inputText, done: false}
    //   ]
    // )

    dispatch({
      type: 'add',
      text: inputText
    })
    setInputText('')
  }

  const handleTaskDelete = (taskId) => {
    // setTasks(tasks.filter(task => task.id !== taskId))
    dispatch({
      type: 'delete',
      taskId: taskId
    })
  }

  return (
    <div>
      <input type="text" value={inputText} onChange={onInputTextChange} />
      <button onClick={handleTaskAdd}>add task</button>

      <ul>
        {tasks.map(task => {
          return(
            <div key={task.id}>
              <p>{task.text}</p>
              <button onClick={() => handleTaskDelete(task.id)}>Delete</button>
            </div>
          )
        })}
      </ul>
    </div>
  )
}

Notice the dispatch() calls?

Instead of a bunch of setState(), we dispatch.

dispatch() usually sends an object consisting of:

the type of action
the payload (text etc)

An example pseudocode:

dispatch({
  type: 'add',
  text: inputText
})

Every time we call dispatch() with the action object along with it, we are essentially calling the reducer that we separated into a part on its own. That reducer would then deal with the logic.

Remember this line from the main file?
const [tasks, dispatch] = useReducer(taskReducer, initialTasks)

initialTasks is fed into tasks as the current state.

Whenever we call the reducer, it handles the logic and returns a new state back to the tasks state variable.

What we have essentially done, is to streamline the state logic.

Do you use reducers all the time? Not really. The general rule of thumb is to use reducers if state starts getting complicated. If it stays simple, use useState().

Observables in SwiftUI

MZ — Wed, 26 Nov 2025 08:11:14 +0000

Observables

This article aims to explain how observables help or fit in into the use case of sharing data among views.

Before that, we need some context.

When we want to share data among views, we usually use classes instead of structs. The main reason is that whenever we use structs, each view will have its own copy of said struct, so it does not really fit the use case if you would like to share data among views. To be able to share data among views, you need to use classes.

import Combine

class Counter: ObservableObject {
    @Published var count = 0
}

The above code contains a class called Counter and it inherits ObservableObject. SwiftUI makes use of the subscriber-publisher model. In this case, the Counter class publishes the count variable.

struct ContentView: View {

    @StateObject private var counter = Counter()

    var body: some View {
        VStack {
            Text("Counter: \(counter.count)")

            Button("increment in parent") {
                counter.count += 1
            }

            ChildView(counter: counter)
        }
        .padding()
    }
}

In the main view, we declare a Counter object and initialise it.

@StateObject private var counter = Counter()

With that code, we now have access to the Counter class. This allows us to change the value of count in the Counter class. Once changed, the class then publishes said changes to any views listening.

We can even pass the Counter instance down to a child class.

The chain of events are as follows:

The data is changed in the main view
The class would publish the changes
The changes would be reflected in the child view

In other words, the child view only observes and display the changes made to the value.

This would be an example of the child view.

struct ChildView: View {

    @ObservedObject var counter: Counter

    var body: some View {
        VStack {
            Text("Counter: \(counter.count)")

            Button("increment in child") {
                counter.count += 1
            }
        }
        .padding()
    }
}

The counter variable is now a parameter for the child view. We do not initialise it here, unlike in the main view. We are only observing from the child view and not actually changing the value. Whatever happens in the main view is then being propagated down to the child view.

This has been the old way. The current code is a handfull. So let's simplify the code.

Let's strip the code down to what we know, without ObservableObject and the @Published keyword.

class Data {
    var firstName = "Mirza"
    var lastName = "Muhd"
}

The logical next step is to do this.

@State private var data = Data()

Notice that it's not @StateObject but @State.

The nuance with this is that SwiftUI watches the data instance itself and not its contents. It ties back into the whole struct vs classes discussion. This is where @Observable comes into play.

You can continue using the above code. You just have to include a few lines.

import Observation
import SwiftUI

@Observable
class Data {
    var firstName = "Mirza"
    var lastName = "Muhd"
}

Now, you can use @State private var data = Data() and the code works as expected.

Behind the scenes, SwiftUI is doing tons of heavy lifting. It's lesser code and looks cleaner.

SwiftUI Shape vs View

MZ — Tue, 09 Sep 2025 19:38:50 +0000

SwiftUI provides a Shape type. This includes Rectangle, Circle etc. Below is the sample code.

var body: some View {
    VStack {
        Rectangle()
            .fill(.red) 
            .frame(width: 200, height: 200) 
    }
}

Right, let's break this down.

With this code, you would actually have a black rectangle that covers the entire screen, except for the safe area and the bottom part of the screen.

var body: some View {
    VStack {
        Rectangle()
    }
}

Why black?

A Shape is just a geometry. A path, if you will. Think of it like an area with nothing inside but an empty space, but it has a boundary. SwiftUI renders a default black "background" so we can actually see there is at least something rendered instead of a transparent rectangle.

Why does it span the entire screen?

A Shape takes after the size or the borders of its parent.

`Shape` versus `View`

Technically, a Shape has no "content". It's literally an empty area. SwiftUI then "fills" that empty area with a black "background". I put background in quotes because it's not technically the background, it's the content.

This is where Shape differs from View. A View already has content. It also has a background property. In a sense, a Shape is a more stripped down version of a View.

Technicalities

This also explains why you cannot apply a frame first. You can only apply a frame if it's a View. Shape is not a View. It only turns into a View once you apply the .fill property. It is a requirement to apply the fill to the Shape, in which case, it turns into a ShapeView, which is a subclass of View.

If you ever take away anything, it is that with Shape, you "fill" it first. A View, on the other hand, lets you set the frame right away.

var body: some View {
    VStack {
        Rectangle()
            .fill(.red) // unique to Shape, returns a View
            .frame(width: 200, height: 200) // you can now apply .frame since it's a View now
    }
}

To make it clearer, here are the differences between a Shape and a View.

Shape

Required to fill the content first. This turns the Shape into a ShapeView, which is a subclass of View
You can then frame the View
Yes, you can also apply a background. But it does get covered by the fill colour.

var body: some View {
    VStack {
        Rectangle()
            .fill(.red) // unique to Shape, returns a View
            .frame(width: 200, height: 200) // you can now apply .frame since it's a View now
    }
}

View

No need for content filling. Views already have a default content to display.
Frame the view
You can apply a background

var body: some View {
    VStack {
        View()
            .frame(width: 200, height: 200) // you can now apply .frame since it's a View now
            .background(.red)
    }
}

.scrollContentBackground(.hidden) for Lists and Forms

MZ — Thu, 28 Aug 2025 14:53:31 +0000

You can apply the .scrollContentBackground(.hidden) modifier to a List or Form to apply a background colour to them.

List and Form are both built from UITableView, so they have commonly inherited properties, and one of them, is the default system background.

You might notice that you are going to be shown the default background colour even if you applied a different colour. To fix this, you need to apply the .scrollContentBackground(.hidden) modifier first before applying another .background() modifier. This way, it tells SwiftUI to remove the default background first before applying a custom background.

Something like this

List {
    ForEach(todos, id: \.self) { todo in
        Text(todo)
    }
}
.scrollContentBackground(.hidden) // remove system background first
.background(Color.blue)

TextField Background Behaviour in SwiftUI

MZ — Wed, 27 Aug 2025 17:50:09 +0000

Technical Notes

`TextField` background

Let's say you have this code:

VStack {
    VStack {
        TextField("type in a todo", text: $textfieldInput)
          .background(.red)
    }
}

In your simulator, or when you run this, TextField will be pushed all the way to the end of the screen (just below the safe area) but its background will include the safe area. Essentially, it would look as if you had a red navigation bar.

This is one of the quirks and technicalities of how SwiftUI handles this.

TextField in SwiftUI does not have boundaries by default. It only has the height of its text. That height is considered its "boundary".
So when you have a TextField pushed up against the top of the screen, SwiftUI sees that and says "Okay, I will push you all the way into the safe area.". Hence why you see the TextField's "boundary" include the safe area.

Couple of things to do, to fix this, and to note, about TextField's behaviour here or the way we attach modifiers to it.

VStack {
    VStack {
        TextField("type in a todo", text: $textfieldInput)
            .padding()
    }
}

When we apply the .padding() modifier, this applies an inner padding to the TextField. What this means is, you will have a bigger tap area and a bigger space for your text inside the TextField to breathe and to be tapped. For clarity, this isn't outer padding. This is the padding inside.

Now, with this small change, your TextField now has a "boundary". Re-run the code, and possibly apply a .background() modifier, and you will see that the TextField now behaves as expected. There are no more unwanted background spillage.

SwiftUI just needs you to express a boundary for your TextField.

Now, you can apply 2 paddings to TextField. One for the inner room for the text to breathe and to make a sizeable tappable space and the other for its actual outer padding.

VStack {
    VStack {
        TextField("type in a todo", text: $textfieldInput)
            .padding()
            .background(.red)
            .cornerRadius(10)
            .padding()
    }
}

Also, as a bonus, another way of making sure TextField behaves correctly is to apply the .padding() modifier to the inner VStack itself. This signifies to SwiftUI that the inner VStack has a boundary, so it would "push" the VStack away from the safe area.

How to pass a variable into your onClick function

MZ — Mon, 16 Jan 2023 14:49:47 +0000

Liquid syntax error: Unknown tag 'endraw'

How to stream RTSP to React using ExpressJS

MZ — Fri, 05 Mar 2021 12:16:22 +0000

Hi, I'm back. I will be showing you how to stream RTSP video input to your React frontend.

RTSP video is generally from your ip camera but it is a type of video format. I struggled with doing this whole project but I have come up with a stable enough project to help you out, if you need any. Also, I'd say the solutions on the web are really all over the place.

I definitely struggled because I didn't know the first thing about RTSP and streaming video.

I'll be using these frameworks/technologies:

You can find the full source code here. I will go over the basics of the code.

We are going to:

use axios to send a GET request to the backend
use ffmpeg to convert RTSP to files (.m3u8 and .ts files)
pipe/insert those files into a HLS(Http Live Streaming) server
send a response back to the frontend once the .m3u8 file has been created
show the video player using a state variable
actually play the video

Use ffmpeg to convert RTSP to files (`.m3u8` and `.ts` files)

The RTSP video format consists of 2 files. The .m3u8 file and the .ts files.

The .m3u8 file is like a directory of where the .ts files are. So the video player needs the .m3u8 file to actually ask for the rest of the .ts files.

The .ts files are segments of the video that has been cut. You can specify the length of each segment using ffmpeg.

This is what the .m3u8 file looks like.

Since both files are needed, our backend does accommodate for these two files, meaning two GET request paths.

Pipe/insert those files into a HLS(Http Live Streaming) server

This is where HLS(HTTP Live Streaming) comes in.

As you can see, there are 2 routes. getManifestStream and getSegmentStream.

getManifestStream serves the .m3u8 file while getSegmentStream serves .ts files.

This code checks to see if the files(.m3u8, .ts) are actually created and makes sure that they are ready to be served/streamed to the frontend.

Send a response back to the frontend

To check if the .m3u8 file has actually been created, I did a check.


 fs.constants.F_OK, (err) =>  {}

This is made in the .on('progress') block of the ffmpeg function which allows you to check on the progress of the file conversion.

If the file has indeed been created, do a res.sendStatus(200).

Show the video player using a state variable

In the frontend, we are at the response block of the axios.get("") function where we will set the state variable to true and ask React to re-render the video player into the DOM.

Actually play the video

The video will play automatically once the .m3u8 file has been loaded. However, as you can see, I set the muted property as such because for some reason (as seen on Stackoverflow), Chrome needed it to be set for the video to play automatically.

Again, it can be overwhelming, so you can find the full source code here.

Different ways of calling a function in a React class

MZ — Mon, 27 Jul 2020 05:01:47 +0000

Let's take a look at this class.

class Clock extends React.Component {
    constructor(props) {
        super(props);

        this.state = {date: new Date()};
    }

    componentDidMount() {
        this.timer = setInterval(() => (this.tick()), 1000);
    }

    tick() {
        this.setState({date: new Date()});
    }

    componentWillUnmount() {
        clearInterval(this.timer);
    }

    render() {
        return(
            <div>
                <h1>Clock</h1>
                <h1>It is {this.state.date.toLocaleTimeString()}.</h1>
            </div>
        );
    }
}

ReactDOM.render(<Clock />, document.getElementById('root'));

As you can see, this is a <Clock /> class.

First Question:

this.timer = setInterval(() => (this.tick()), 1000);

Why does this work instead of, say:

this.timer = setInterval(this.tick(), 1000);

The first one sets a function as a callback to the first argument of setInterval and actually calls the function in the callback.

The second invokes the function on load.

Second Question:

Let's say I want to put the code as:

this.timer = setInterval(this.tick, 1000);

Can you? Yes, you can.

You would have to bind the function in the constructor.

constructor(props) {
        super(props);

        this.state = {date: new Date()};

        this.tick = this.tick.bind(this)
    }

Why? Well, you actually have to call the function and that is what binding does behind the scenes.

However, if you don't want to explicitly bind the function, you can declare it using the ES6 arrow syntax.

tick = () => {
    this.setState({date: new Date()});
}

This achieves the same effect of binding.

Thus, you can still do this, without having to explicitly bind the function.

this.timer = setInterval(this.tick, 1000);

If you want to know more about binding, I will refer you to this very comprehensive guide on binding. It got technical pretty fast for me, so take your time.

If you're wondering how I found it, I was looking through the React website and found the link.

I hope it helps you!

what's the difference between () => {} and () => ()

MZ — Mon, 27 Jul 2020 04:42:30 +0000

Hey there, I'm going to be honest. This is a post that I will make for myself for reference. I've just started learning React and I got a little confused.

So, what's the difference between () => {} and () => (). I asked around and this was what I got.

() => {} is this:

() => {
   return something
}

() => () is the same but without the explicit return statement:

() => (
   something
)

It is mostly a one-line return statement. So it essentially comes down to a simplified version, which is:

() => return something

Or you can just do

() => something

There is also another form where you return a component.

() => <Component />

However, can you do this?

() => (
   var i = 0
   var a = i + 1 
   return a
)

This concludes to this:

() => (
   return var i = 0var a = i + 1 return a
)

While that is wrong, you can do this.

() => (
   return(
    <div>
        <p></p>
    </div>
   )
)

If you still feel slightly wonky about this, it is better to resolve to () => {} this first.

Feel free to correct me if I'm wrong ya!

How to make the HTML input fit the containing div

MZ — Mon, 06 Jul 2020 04:13:37 +0000

Hey there!

I wanted to challenge myself to write a technical post again so here I am. I've recently gotten to writing up a todo app in React and came across this issue. It's simple to solve but I thought, why not do up a blog post on it?

This is my code.



<div id='main-div'>
  <div id="inner-div">
      <input id="text-input" type="text" value={this.state.obj.text} placeholder="Enter todo item" onChange={this.handleChange} /> 
  <div>
</div>

This is my code structure, simplified.

However, when you run this, you get this.

I have sort of colour-coded the different divs. Red indicates the main div while blue indicates the inner div.

Notice how the input is overflowing out of the inner div?

So, apparently this is a thing in CSS or HTML. I searched it up and found this answer.

From the answer, I understand that there is a bounding border box on the input tag. If you use the box-sizing: border-box; style with the input tag, this actually places the bounding box inside the tag.

The input tag appears bigger because the bounding box appears outside of it, initially.

It's an interesting property to have.

Well, this has been short but sweet. Hope anyone who comes across this post learned something or have fixed their issue.

Thanks for reading!

Create out of curiosity

MZ — Wed, 10 Jun 2020 15:58:58 +0000

I remembered back then when I was first given an assignment to do up a calculator in Android. I think it was my first Android project.

I remember using XML to design the interface and I thought, wow, this was very restricting. We were given the whole semester(?) to do it but I was done by the second week. I focused on the logic more than the design. I was stuck on something for quite a bit. I think I was being super ambitious. But I just had fun helping my friends throughout the course.

Such simple times when there was literally no pressure to create. I was creating out of curiosity. Be like, what would it be like to create a Twitter clone or a Tinder clone?

We learned JSP and I was literally like sky-high with confidence because I remember I wanted to create web applications. I just didn’t know where to start at that time. There were a lot of tech around. I really thought I had to learn jQuery and PHP to start. But JSP came and I had Java knowledge already, so why not?

I wanted to go back to my roots and just create out of curiosity. I think that's a beautiful first step.