- TechDailyFeed - Your Daily Dose of Tech News, AI, Programming, and More

Hey there! Hope you're having a great week! I'm building Cardboard, a straightforward, yet powerful reactive web framework. You can look at the repo, or the other articles in the series if you don't know what Cardboard is about! This post is a devlog/changelog about what's happened with Cardboard in the last update. What's been added, changed, and improved. Changes State I've re-written the state to use Consumables. I decided to do this as the previous implementation of the state was unstable, hacky and not very intuitive to be honest. Consumables are custom objects that hold a value, can be listened for changes, and can dispatch new values. Another inconvenience was that you could only create object/array states, not primitive values. With the new implementation, you can have both. By using Consumables the new state is simplified. It's also a lot more stable and intuitive. Before: let st = state({ count: 0 }); st.count++; Now: let count = state(0); count.value++; Now we must modify the value of the consumable. There are many more changes, but not worth mentioning as they're not that interesting :P Additions States can now be children To be able to create reactive text before, you had to use the text function or tag.text method. While that did the job, it was a pain if you just wanted to add the Consumable value without interpolating. Let's look at an example to better understand what I mean: Before: const hours = state(0); const minutes = state(0); div(text('$hours', { hours }), ':', text('$minutes', { minutes })); Now: const hours = state(0); const minutes = state(0); div(hours, ':', minutes); Consumable Intersecting When using Consumables, you might want to check if it has a value, if it's empty, if it's a certain value, etc... For this, Consumables can be intercepted, which means that you can create a new Consumable that updates its value based on another Consumable. Look at this example: const temperature = createConsumable(32); const isTooHot = greaterThanOr(temperature, 30); div().showIf(isTooHot); As you can see this can be very powerful. isTooHot will be true if the temperature is higher or equal to 30, and false if less. The div will be shown or hidden based on the value of isTooHot. Let's look at another example: const TodoItem = (todo: IConsumable) => { const isComplete = grab(todo, 'complete', false); const todoText = grab(todo, 'text', 'Empty Todo'); return div( input().setAttrs({ type: 'checkbox' }) .changed((self) => { todo.value.complete = self.checked; }), h4(todoText) .stylesIf(isComplete, { textDecoration: 'line-through' }), ); } grab will set its value to a specified value from the original consumable. Whenever todo changes, the values of isComplete and todoText will also update. If the input checkbox is changed, it will set the complete property. When this happens the h4 will react and set the styles accordingly. I'm interested in knowing what you think about this. Do you think the approach I've taken is good? Or would you suggest going another route? each The biggest change has been the addition of the each function. This has taken most of my time and has made me rethink how some aspects of the project work. Most other changes have been made to make each work properly. each renders lists that update whenever the state changes. The interesting and hard thing is that it's smart and will only update the things that need to be updated. If a value is added, only that value is added to the dom. If a value changes places, only that operation is done. This was a bit of a challenge, not only creating the actions to be performed but also handling memory. This is how it works: const colors = state(['red', 'orange', 'yellow', 'green', 'blue', 'indigo', 'violet']); const selectedColor = state('red'); div( each(colors, (color) => button(color) .addStyle('color', color) .stylesIf(equalTo(selectedColor, color), { fontWeight: 'bold' }); ) ); If a colour is added, removed, or changed places, each will react and update the list accordingly. If you want me to write a more detailed and technical article about how each works, let me know in the comments and I will get to it. It's pretty interesting! Improvements After working on all of the changes mentioned above, and adding more tests a lot of bugs have been squashed, naming has improved, and the overall stability of the project has increased. Additionally, I've spent a lot of time improving the wiki and docs, as well as the README. I think having a decent Wiki and documentation is key from the get-go. Summary It's been a productive couple of weeks. I don't think I've ever spent this amount of time working on a single project (outside of work). But I like how Cardboard is turning out! I

Mar 17, 2025 - 11:17

Hey there! Hope you're having a great week!

I'm building Cardboard, a straightforward, yet powerful reactive web framework. You can look at the repo, or the other articles in the series if you don't know what Cardboard is about!

This post is a devlog/changelog about what's happened with Cardboard in the last update. What's been added, changed, and improved.

Changes

State

I've re-written the state to use Consumables. I decided to do this as the previous implementation of the state was unstable, hacky and not very intuitive to be honest.

Consumables are custom objects that hold a value, can be listened for changes, and can dispatch new values.

Another inconvenience was that you could only create object/array states, not primitive values. With the new implementation, you can have both.

By using Consumables the new state is simplified. It's also a lot more stable and intuitive.

Before:

let st = state({ count: 0 });
st.count++;

Now:

let count = state(0);
count.value++;

Now we must modify the value of the consumable.

There are many more changes, but not worth mentioning as they're not that interesting :P

Additions

States can now be children

To be able to create reactive text before, you had to use the text function or tag.text method. While that did the job, it was a pain if you just wanted to add the Consumable value without interpolating. Let's look at an example to better understand what I mean:

Before:

const hours = state(0);
const minutes = state(0);

div(text('$hours', { hours }), ':', text('$minutes', { minutes }));

Now:

const hours = state(0);
const minutes = state(0);

div(hours, ':', minutes);

Consumable Intersecting

When using Consumables, you might want to check if it has a value, if it's empty, if it's a certain value, etc...

For this, Consumables can be intercepted, which means that you can create a new Consumable that updates its value based on another Consumable.

Look at this example:

const temperature = createConsumable(32);
const isTooHot = greaterThanOr(temperature, 30);

div().showIf(isTooHot);

As you can see this can be very powerful. isTooHot will be true if the temperature is higher or equal to 30, and false if less.

The div will be shown or hidden based on the value of isTooHot.

Let's look at another example:

const TodoItem = (todo: IConsumable<TodoItem>) => {
  const isComplete = grab(todo, 'complete', false);
  const todoText = grab(todo, 'text', 'Empty Todo');

  return div(
    input().setAttrs({ type: 'checkbox' })
      .changed((self) => {
        todo.value.complete = self.checked;
      }),
    h4(todoText)
      .stylesIf(isComplete, { textDecoration: 'line-through' }),
  );
}

grab will set its value to a specified value from the original consumable. Whenever todo changes, the values of isComplete and todoText will also update.

If the input checkbox is changed, it will set the complete property. When this happens the h4 will react and set the styles accordingly.

I'm interested in knowing what you think about this. Do you think the approach I've taken is good? Or would you suggest going another route?

`each`

The biggest change has been the addition of the each function. This has taken most of my time and has made me rethink how some aspects of the project work. Most other changes have been made to make each work properly.

each renders lists that update whenever the state changes. The interesting and hard thing is that it's smart and will only update the things that need to be updated. If a value is added, only that value is added to the dom. If a value changes places, only that operation is done.

This was a bit of a challenge, not only creating the actions to be performed but also handling memory.

This is how it works:

const colors = state(['red', 'orange', 'yellow', 'green', 'blue', 'indigo', 'violet']);
const selectedColor = state('red');

div(
    each(colors, (color) => 
        button(color)
          .addStyle('color', color)
          .stylesIf(equalTo(selectedColor, color), { fontWeight: 'bold' });
    )
);

If a colour is added, removed, or changed places, each will react and update the list accordingly.

If you want me to write a more detailed and technical article about how each works, let me know in the comments and I will get to it. It's pretty interesting!

Improvements

After working on all of the changes mentioned above, and adding more tests a lot of bugs have been squashed, naming has improved, and the overall stability of the project has increased.

Additionally, I've spent a lot of time improving the wiki and docs, as well as the README. I think having a decent Wiki and documentation is key from the get-go.

Summary

It's been a productive couple of weeks. I don't think I've ever spent this amount of time working on a single project (outside of work). But I like how Cardboard is turning out! I think that with a bit more work it can be very powerful and competent.

I'm aiming to have the first stable version finished before the end of the year!

If you find the project interesting please consider helping out!