DEV Community: GlyphCat

State Management with React Relink

GlyphCat — Fri, 27 Nov 2020 13:00:35 +0000

Relink is a React state management library inspired by Recoil.

Recoil is Facebook's experimental state management library. Shifting from Redux, I have been using Recoil for more than half a year and so far it worked well me. But the downside is that the documentations are not very complete and it comes with features that I find myself never using. For things that I do need, I find myself resorting to rather awkward workarounds.

One thing that I have yet to find a workaround is to get it to work with React Native Navigation. In RNN, each screen has a separate React component tree. State updates do not occur across screens since every screen is wrapped in their own .

Sure, there are other tools out there that can help with state management, but since it can also be an interesting learning experience for me, I've decided to create my own state management solution.

Relink

I call it Relink (or React Relink, since the name relink has been taken on NPM). Part of how Relink works is similar to Recoil. I've made it that way because I find Recoil's convention rather easy to understand.

The source code is currently available on GitHub and the package on NPM. If you find it helpful or simply intriguing, do consider giving it a star on GitHub 😉.

Below are just some basics, detailed documentations are available in the readme file.

1. No provider components required 🤯

import { createSource, useRelinkState } from 'react-relink'

const ScoreSource = createSource({
  // key must be unique
  key: 'score',
  // This is the default state
  default: {
    red: 0,
    blue: 0,
  }
})

function App() {
  const [score, setScore] = useRelinkState(ScoreSource)
  return /* ... */
}

Create a source then use it with a Relink hook and that's it.

Under the hood, Relink hooks use listeners to trigger component updates. The states become accessible (or linked) across different React component trees since there are no providers. This is also the main reason it's called "Relink".

Of course, I can't say for sure if providers are necessary and whether eliminating the need for providers will cause problems, but that shouldn't be a big concern as long as the keys are unique.

2. Hydration & Persistence 🌱

The code for managing data hydration and persistence are kept close to the source creation. You don't only have a single source of truth, but a single place to keep your hydration/persistence logic.

const counterKey = 'counter'
const counterDefaultState = 1

createSource({
  key: counterKey,
  default: counterDefaultState,
  lifecycle: {
    // Hydration
    init: ({ commit }) => {
      const data = localStorage.getItem(counterKey)
      commit(data ? JSON.parse(data) : counterDefaultState)
    },
    // Persistence
    didSet: ({ state }) => {
      localStorage.setItem(counterKey, JSON.stringify(state))
    },
    // Persistence by cleaning up
    didReset: () => {
      localStorage.removeItem(counterKey)
    },
  }
})

3. Extra Options ⚙️

• Suspense components during hydration
By default, hydration happens synchronously. If you're fetching data from the server, then you'll either need to turn this on or conditionally render a loading UI while hydration is in progress. This is disabled by default because it relies on an experimental React feature.

• Enable mutability
In case you desperately need some performance improvement, you can enable mutability. This is disabled by default because it might lead to unwanted side effects.

• Virtual batching
Meant to improve performance by batching Relink's listener updates before triggering component updates on top of React's unstable_batchedUpdates. This is disabled by default because it used to result in faulty component updates in the early stages and the improvements are not obvious.

createSource({
  key: string,
  default: any,
  options: {
    suspense: boolean,
    mutable: boolean,
    virtualBatch: boolean,
  }
})

(extras)

A Funny Observation

There's a funny thing that I learned along the way. At first I wanted to make it usable in React & React Native using the same bundled code but apparently it lead to bugs 🐛. In the end, I had to create different bundles for React DOM and React Native.

As mentioned previously, Relink uses listeners. At first, I relied on useEffect to add/cleanup the listeners and it created a rather confusing error. Imagine 3 components subscribing to a listener. The listener callbacks are called from components A to C in a for-loop.

┳━━━ <ComponentA />
┗━┳━ <ComponentB />
  ┗━━━ <ComponentC />

const keyStack = Object.keys(listeners)
for (const key of keyStack) { listeners[key]() }

The callback for Component B is called and there's a chance it can cause Component C to unmount. Then when calling the callback for Component C, the callback becomes undefined since it has been removed in the cleanup function.

Using for (... i < listeners.length ... ) or for (... i < Object.keys(listeners).length ... ) seemed to help a little, but it is still possible for the array of callbacks to change before a loop can complete.

In the end, I resorted to useLayoutEffect and React's unstable_batchedUpdates. This helped to batch the renders together and solved the problem. However, the logic for batching component updates for browsers and mobile platforms are different so they need to be imported from either 'react-dom' or 'react-native' depending on the environment. Hence, different code bundles need to be generated.

I have also considered using linked lists but yet to test it out. Since it's already working, I'm leaving the code as it is for now. :3

The Bottom Line

Don't reinvent the wheel, use what's already made by others — this is usually true. But when they start to function awkwardly, you might wanna consider manufacturing your own wheels.

Facebook created Recoil to tailor to their needs despite already having several state managing solutions out there. The same can be said about Relink.

Of course, nothing is perfect. If state management is important to you but nothing's working quite right and you have the capacity, may be you should try creating a solution that fits you too. 🍻

Enabling Exclusive Content with Web Monetization: The Right Way

GlyphCat — Fri, 26 Jun 2020 09:26:34 +0000

In a previous post, I talked about how payment pointers can be modified just like any other HTML element in the DOM tree.

I came up with a solution to deal with it, if not, at least make it harder for the payment pointer to be tampered with. But as I kept on researching, I found yet another way from technical specifications in the WM (Web Monetization) official site. It's not necessarily "the only right way", but it is a rather practical way.

The Missing Part

The thing is, not even the complete example given by WM mentions about it.

When a transaction occurs and a monetization event is emitted, you can (and should) check its payment pointer via event.detail.paymentPointer, if the payment pointer is different, stop showing exclusive content immediately.

  if (document.monetization) {
-   document.monetization.addEventListener('monetizationstart', () => {
+   document.monetization.addEventListener('monetizationstart', (event) => {
+     if (event.detail.paymentPointer === MY_PAYMENT_POINTER) {
        showExclusiveContent()
+     } else {
+       hideExclusiveContent()
+     }
    })
  }

Note:

This code is based on a small portion from the example by WM
I would suggest adding a listener for 'monetizationprogress' and check the payment pointer too just in case.

For reference purposes, below is a screenshot showing the details from an emitted monetization event:

So now,

You know the concept of enabling exclusive content by making sure you get paid for it... with a client-side approach at least. (￣▽￣) And I'd say the Payment Pointer Protection approach is still relevant as it acts as an additional layer of safeguard. After all, it's a thing that takes place in the browser. We don't have as much control over the things that happen as we do in the backend.

With that said, I shall post more updates on this topic should I find something interesting. Until then, peace. ✌️

Making Your Payment Pointer "Read-only"

GlyphCat — Fri, 26 Jun 2020 02:17:36 +0000

DEV is now Web Monetized and Web Monetization itself seems to be gaining more attention lately. I started playing around with it out of curiousity. It was when I noticed a problem but not sure how great the impact would be.

So I'm taking this opportunity to share a solution that I came up with, and I'd like to know your thoughts on the problem itself.

The Problem

The payment pointer is just a <meta> tag. Its value can be changed from a browser's element inspector and possibly through script injection.

The specification states that:

The user agent generates a fresh random UUID (version 4) and uses this as a Monetization ID. This MUST be regenerated upon dynamic changes to the meta tags and MUST be unique per page load in order to avoid user tracking.

This means they are allowing the payment pointer's value to be set dynamically, right? But what if people somehow modified our payment pointer and set it to theirs while consuming our content? Yikes.

Edit: So I was still doing research after finish writing this article and found something else helpful. It's a more practical way to protect your web monetized content. I've written a separate article to explain how that method works. Nonetheless, this article will still remain relevant so please keep on reading.

A Solution

So I started to think about ways that can protect the payment pointer, or at least, make it harder for people to tamper with and finally came up with a solution in written in JavaScript.

It's designed (but not guaranteed) to prevent people from:

Removing your payment pointer
Modifying your payment pointer
Inserting their own payment pointer

Only time can tell if it's reliable.

The way it works is pretty simple:

import PaymentPointerProtector from './payment-pointer-protector'

const paymentPointer = '$example.payment.pointer'
const p = new PaymentPointerProtector(paymentPointer)

// Start watching
p.guard()

// Stop watching
p.release()

There's also a wrapper that you can use in React.

import PaymentPointerProtector from './payment-pointer-protector/react'

const paymentPointer = '$example.payment.pointer'

function App() {
  return (
    <PaymentPointerProtector paymentPointer={paymentPointer} />
  )
}

If you already have a payment pointer in the head your HTML, it will look for the tag and guard it. Otherwise, it will add one for you then guard it.

The payment pointer literally becomes read-only.

Deleting the node will not seem to have any effect.

Other payment pointers, if added, will be removed immediately.

It's available in this GitHub Repository. You'll either have to clone or copy from the raw file and add it into your project manually. By the way, I would like to make it into a package and put it up on NPM to make it work like React where people can use it either through unpkg.com or npm install but I'm facing some difficulties here. I'm not sure how long it will take me for this to happen, so if you have spare time and energy to help me out, I'll be more than glad.

Bottom Line

It's possible for people to mess with the payment pointer
The Payment Pointer Protector is designed to deal with this problem

But another problem worth thinking about is, should it be up to the developers to deal with this problem? Or perhaps browsers should make an exception to check for the presence of a payment pointer and guard it?

I can imagine scenarios where people would want to change the payment pointer dynamically. It can be for testing or alternating-interval-based revenue sharing (although Probabilistic Revenue Sharing is the recommended way). These things would become impossible and out of our control if it becomes a standard that browsers should automatically guard payment pointers.

What are your thoughts on this?

Thoughts On What I Have Learned From College

GlyphCat — Thu, 25 Jun 2020 04:16:22 +0000

A preface question: How much have you learnt from college or through some other traditional education means and to what extent do you find them useful today?

Let me start with my story.

Diploma

I started to learn coding on my own in high school. In diploma, I get to properly learn a few things and they help solidified my basics. I also get to expand my network by making new friends. Great. I was taught some algorithmic thinking, object-oriented programming, HTML & database basics. My self learning was focused on React, React Native, NodeJS, Firebase, npm, things like that.

There was also an internship but none of the things I learnt so far were relevant to the job scope. I managed to secure my internship position as an iOS software developer probably thanks to my exposure in mobile app development with React Native.

Degree

Moving on to degree, not so great. I didn't pick up as much useful skills as before, assignments were stacking up and there was less time to socialize.

At the same time, I was working part time as a React Native developer for a company. I was exposed to some paid developer tools/APIs that I could not have learn by myself or through college. There was also once I was tasked to add a new feature to a nearly-complete app and straight deploy it to Play Store and App Store. It was a small one tho.

Then there's another internship. Guess what? Nothing I learnt in college were relevant to this one either. I worked as a web developer (using React and ASP.NET) this time.

The Present

This is where I am right now. With two more semesters to go. There's a subject called Agile Development, where we learn how to manage the way we manage things and structure the way we structure things... literally anything but to code with agility. I've been working in three different environments at this point of time and needless to say, I already know how messed up "agile" is. (Disclaimer: it is has its fair share of pros and cons, but most companies today are overhyping it and have mistaken/twisted its concept)

There's also a Final Year Project. None of the things learnt in college were useful enough, my topic was rejected, and the (self-taught) development stack that I proposed for my topic was said to be too simple. Wait, what? So I was never taught anything powerful enough to build a complete and working project, but now I'm suddenly expected to prove what I've learnt by building a flying unicorn and not even my self-taught skills are enough?

What the meow!

Doubts

I'm having very serious doubts. The only thing I feel like I've learnt in degree is time management and nothing more. Some of my friends are telling me that I should be thankful that my parents can afford to get me into college and I understand that. But at the same time I'm starting have some slight regrets. I could've spared my parents' money. I could've started working or focus on my side projects and make them a thing or do something useful instead of building some superficial unicorn app that's heavily valued from an academic perspective but may not have any value to the real world.

I studied degree for three reasons:

I thought it was the norm after graduating from high school (at least in where I live)
(because of #1) I thought I could improve myself as a developer and feel more secure... 😂
I was afraid of disappointing my parents

I'm from an Asian family by the way. My parents never said anything unpleasant to me or forced me, but I know deep down they really want me to get good education, proper certification and have a decent job because they care for me. It would definitely worry them if I suddenly acted different from everyone else. But as time passes I start to realize that this type of certifications are really not for everyone. Most of these certifications just pave way for individual to work for someone else (eg: office work). Just like how a lot of people about my parents' age are living.

It didn't feel like my confidence increased, nor did I feel more secure when I think about looking for jobs or paying bills. I'm now in that mentality where I'm just scraping by my courses, putting in as little effort as possible into my so called academics and reserving them for my own side projects that I'm certain will be useful to me in the future. There's still a chance they might fail but at least I've tried. I'd rather be happy living a simple life than to earn a boatload of money but living in constant unhappiness.

What Can You Take Away from My Story?

People may tell you to at least get a degree, but I ask you to think properly if it's really what you need and if it's going to add value to your future. There are even articles about Elon Musk saying degree certifications are not necessary.

It's up to you to decide whether to further your studies or to step out and start working early or do your own things and generate revenue from it. If what you plan to do really needs some sort of certification then by all means go for it, but if you want to get a certification for your someone else's sake or just to feel more secure, then I suggest you to reconsider it.

After all, life is like driving a car. People can give you directions out of kindness, some can get mad at you for not listening to them, but at the end of the day you're the one in control of the car and if there's a crash, no one is going to be responsible for it except you.