DEV Community: joon

My experience skimming the cutting-edge dream front-end stack

joon — Sat, 22 May 2021 15:14:06 +0000

Probably going to be a quick and messy post. More of a dev log. Keep this in mind and try to bear with me.

TLDR; I tried using Vite + svelte + tailwind stack. As a React / Nextjs developer, I don't think I'll be using vite with svelte or either separately anytime soon.

A backend co-worker introduced this post a few weeks ago and since then I had vite under my radar for a bit.

Quite recently I started experiencing performance issues in my code and I started to wonder whether ditching React for svelte in high-frequency data handling required scenarios might be a good idea. (The performance issues were resolved by throttling renders so it wasn't really necessary)

And suddenly on a Saturday night, I thought 'f* it, let's give it a go'

I literally copy & pasted this code added all the dependencies via the CLI to use the latest ones, fixed some settings here and there until finally yarn dev displayed the following.

Vite is fast. But...

Comparing the time for the website to appear from the moment I press enter on yarn dev? Not really. You know that animated circle next to the tab that goes round and round in a mesmerizing way when the site is loading? It took that exactly 4 cycles for a very simple site to load. Honestly, I think my nextjs setup would've been faster. (I presume that the speeds could increase in scale, but I wasn't willing to test that)

Obviously, it was not a properly tested benchmark but just a 'feeling' - but whether or not this 'feeling' was misplaced or not, conclusively I didn't really feel like the hassle of switching was worth it.

and worst of all

11:46:54 PM [vite] Internal server error: No parent could be found
  Plugin: vite:css
  File: /Users/my-directory/svelte-vite-ts-tailwind/src/Wisdom.svelte?svelte&type=style&lang.css
      at /Users/my-directory/svelte-vite-ts-tailwind/src/Wisdom.svelte?svelte&type=style&lang.css:1:188
      at findParent (/Users/my-directory/svelte-vite-ts-tailwind/node_modules/tailwindcss/lib/lib/substituteClassApplyAtRules.js:218:9)
      at /Users/my-directory/svelte-vite-ts-tailwind/node_modules/tailwindcss/lib/lib/substituteClassApplyAtRules.js:228:33
      at /Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:151:16
      at /Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:74:18
      at AtRule.each (/Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:60:16)
      at AtRule.walk (/Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:71:17)
      at /Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:79:24
      at Root.each (/Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:60:16)
      at Root.walk (/Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:71:17)
      at Root.walkAtRules (/Users/my-directory/svelte-vite-ts-tailwind/node_modules/postcss/lib/container.js:149:17)

what? I had no idea what to do with this error and the stack trace did 0 help.

Google?
not really helpful at all.

It wasn't hard to land at my personal conclusion - vite may or may not have amazing DX perks speed-wise at scale, but realistically speaking, it's not going to reduce dev times but increase it at its current state.

About tailwind

Since I personally hate css, ever since I tried tailwind I've never looked back - it's a godsend imo. Use it whenever possible if you're like me.

About Svelte

This is a very biased opinion coming from a React/Nextjs fanatic. So svelte doesn't seem to even want to support multiple components in a single file - link. And I respect that. But personally I think file splitting should be an option and not mandatory. And the second I saw that it wasn't possible, it was a red flag for me.

Also, the syntax personally felt very alien but this is obviously due to myself being too accustomed to React's syntax. But the await - then syntax above looked awesome for quick prototyping. Other than that, I haven't looked too deep into svelte to give any other opinion.

Wrapping up.

Svelte's speed benefits? I'm sure they're plenty. But I think I'll manage atm.

Vite? Until the majority of probably frequent errors show up on the first page of search results on google - No.

I think I'll stick to nextjs/tailwind for the time being.

What's your opinion on data-first frontend ?

joon — Tue, 18 May 2021 18:55:34 +0000

Read first

2 years into my front-end career, I'm handling projects that I really feel like I need to be studying hard CONSTANTLY in order to reduce technical debt to a minimum.
And then I come across this post which almost convinced me it's the right way to go.

It's time for a revolution in data-first frontend frameworks, which relegate React to what it does best: rendering and diffing DOM nodes. Values in, actions out. No useState. No useEffect.

...

It's time for a change. It's time for a paradigm shift. It's time for a revolution in data-first frontend frameworks that control the view layer and not the other way around.

Reading the above 2 paragraphs, I was almost convinced I needed to refactor everything in order to make this possible.

The topic is not whether Kea is the framework to use - but whether this is the right mindset. Throughout my career, my coding style focused on trying to keep as much of the application state non-global as possible. This post was challenging the very fiber of the thought-process I've been trying to perfect through my frontend career.

From that moment forward, I would see this everywhere. If ever I felt like my program was getting too complicated or hard to read, it was almost always a data structure problem

This part honestly - I agree 110%. It actually feels exactly like the state of a project that is increasingly getting harder to develop / maintain.

But is this what I should be focusing on?

Since my thought process has started to really jump out of the box, maybe I'm focusing on the first seemingly radical idea that I randomly came across that seemingly fits?

Namely,
Is this Input-Data-View layer parallel hierarchy the way to go?

What are your thoughts?

Make your own state management for React with Proxies and Event emitters

joon — Wed, 25 Nov 2020 15:35:38 +0000

Intro

Easing into the subject

I think it took about 6 months before I got comfortable with 'using Redux'. 16 months in and I've yet to become comfortable with 'Redux itself'. Personally, I do realize why Redux is needed in large apps with scalability requirements, and for that matter - redux is a pure god-send. However for the majority of smaller apps, redux's cons could outweigh the pros depending on the circumstances

Actions are rarely reused
Being forced to separate logic
What Dan says

What about Context API and other state management libraries?

As with every other package, depending on the project at hand, there could be alternatives that better suit your needs. But why not try making your own? So I started digging into the matter - what's the easiest way to create a global state management library?(Yes there is a lot of reasons to not try making your own but bear with me)

TLDR - the results

If you'd rather read the source code (npm package)

Ok, but why would I make one myself?

What better way to show interest in a subject than say 'I tried making one myself, here are the results'. Possibly the best interview question answer.(Obviously after a lengthly description about various state management libraries and your experiences)
Demystifying the possibly vague concept and mechanisms of global state management.
With an understanding of how to start off, customizing for your project might take less time in setting up than actually easing into other global state management like redux which have quite the learning curve.
Honestly there's not much reason, I just though I'd share my experience in the form of a tutorial. Learning redux(if you already haven't) is far more beneficial for most people and large scale app scenarios.

Why proxies and events instead of useState and hooks

So before I begun tackling the matter, I wanted to avoid making anything from React mandatory for the following reasons

To make React optional(obviously)
Finer controls over the store
Most importantly, make the store updatable without having to drill update functions from a React component.

Personally I was fed up with having to drill store dispatchers through multiple functions since I had begun to move onto a more javascript focused coding style. My first attempt was by using rxjs's observers and observables to make this possible. It worked, but the rxjs dependency felt heavy for sites that needed minimal bundle size. So after a fair bit of researching, proxies paired with events felt like the perfect choice.

Proxies

The closest thing that mimics c++ operator overloading in js would be my first impression.
But in reality it's a wrapper that allows you to define custom functionality for otherwise un-editable functions. Pair it with Reflect, and you can keep normal functionality and just have side effects.(This is a personal opinion and can be disputable - if so, let me know in the comments)



const store = {};
const storeProxy = new Proxy(store, {  
    set: function (obj, prop, value) {  
        obj[prop] = value;
        //  my custom set logic
        //....
        console.log(`I'm setting ${prop} to - `, value);
        return true;  
    },
    get: function (target, prop, receiver) {
        const obj = Reflect.get(...arguments);
        //  my custom get logic
        //...
        return obj;
    }
});

Now if you edit the store using the storeProxy like this



storeProxy.foo = "bar";

You'll see the custom set logic being executed. Kind of like an observer observing an observable!
On a sidenote, try creating an array with about 10 values, create a proxy that counts set operations, then pop a value and shift a value. You'll see why shifting values take O(n) time while popping take O(1) quite visually.

EventEmitter

Using CustomEvents and dispatching to the DOM works as well when using pure React. However in scenarios where the DOM is inaccessible (SSR or SSG using Nextjs for example), that could not be an option. Also events from event emitters have less dead-weight since they do not propagate or bubble anywhere.

Walkthrough

I eventually refactored my codebase to a Class based approach, but we'll do a functional approach for the sake of a wider audience.

Disclaimer I did not try out any of this code and there could be mistakes. Any form of constructive criticism is appreciated. The code below should serve as a guideline but could also work as intended. No promises :). The github repo in the TLDR section is working code.

Step 1 - The building blocks



//  because using document events doesn't work on SSG / SSR  
const Emitter = require("events")
const EventEmitter = new Emitter()

//  virtually no limit for listeners  
EventEmitter.setMaxListeners(Number.MAX_SAFE_INTEGER)  

let eventKey = 0  
export const createStore = (initObj) => {  
    //  underbar for private methods / vars  
    const _evName = `default-${eventKey++}`

    const _store = cloneDeep(initObj) //  preferred deep cloning package, recommend rfdc

    const _storeProxy = new Proxy(store, {
        set: function (obj, prop, value) {
            //  apply options, restrictions pertaining to your needs
        }
    });

    //  dispatch logic to use when store is updated  
    const _dispatchEvent = () => {  
        EventEmitter.emit(_evName)  
    }
    // ... the HOC and update logic
}

So this is the barebones version. Bear with me.
Underbars are in front of all declarations to simulate private declarations that won't be exposed outside.
_evName is defined so that events can be distinguished among multiple stores

Step 2 - The HOC and update logic



// ... the HOC and update logic
    const updateStore = obj => {  
         //  only update store when obj has properties
        if(Object.getOwnPropertyNames(obj).length < 1) return;
        //  update logic via storeProxy
        Object.getOwnPropertyNames(obj).forEach(key => {
            //  possible custom logic
            _storeProxy[key] = obj[key];
        });
        //  dispatch for EventEmitter
        _dispatchEvent();
    }

    const getStore = () => return {..._store};

    const createUseStore = () => {  
        //  purely for rerendering purposes  
        const [dummy, setDummy] = useState(false);  
        const rerender = useCallback(() => setDummy(v => !v), [setDummy]);  

        useEffect(() => {  
            const eventHandler = () => rerender();  
            EventEmitter.on(_evName, eventHandler);  
            return () => EventEmitter.removeListener(_evName, eventHandler);  
        }, [rerender]);  

        //  only updates when the above event emitter is called
        return useMemo(() => {
            return [this._store, this.updateStore];
        }, [dummy]);
    }
    return [createUseStore, updateStore, getStore];
}

The actual update logic and the HOC are suddenly introduced and step 1 starts to make sense. The code is possibly simple enough to understand as it is, but here's how the logic goes.

An event emitter is defined(globally)
A store in the form of a js object is created
A proxy is created that proxies the store with custom logic.
updateStore is defined that sets the value for each key to the proxy, then dispatches the event
getStore is defined that returns the current store deep-cloned.
A HOC is defined that returns the store and update function.

Step 2.5 - Step 2 MVP in action



import {createStore} from "where/you/put/your/createStore";

const initMyStore = {
  foo: bar
};
const [createUseMyStore, updateMyStore, getMyStore] = createStore(initMyStore);
const useMyStore = createUseMyStore();

export { useMyStore, updateMyStore, getMyStore };



import * as React from "react";
import {useMyStore} from "the/initcode/above";

export default function MyComponent() {
    const [store] = useMyStore();
    return (
        <div>{store?.foo}</div>
    )
}



//  in another file far far away.....
import {updateStore} from "the/initcode/above";

function aFunctionNestedInside50Functions () {
    updateStore({foo: "barbar"});
}

As stated above this is a barebones MVP, meaning that a LOT of core functionality that are usually expected for a global state management package are currently stripped away such as

selective event dispatching
selective property watching
immutability or selective immutability
Container predictability
A LOT of safeguards that other global state management packages supply by default.

For the majority of simple apps, the above code + returning a deep copied / deep frozen version on 'get' should be enough.
Let's try expanding functionality to allow selective state updates and event dispatches

Step 3 - Functionality expanding



    //...

    //  dispatch logic to use when store is updated
    //  updated keys are emitted to event emitter
    const _dispatchEvent = (keys) => {
        EventEmitter.emit(_evName, keys)
    }
    // ... the HOC and update logic
    const updateStore = obj => {
        //  only update store when obj has properties
        if(Object.getOwnPropertyNames(obj).length < 1) return;
        //  keys are stored to pass to dispatchEvent
        let keys = [];
        //  update logic via storeProxy
        Object.getOwnPropertyNames(obj).forEach(key => {
            //  possible custom logic
            _storeProxy[key] = obj[key];
            keys.push(key);
        });

        if(keys.length < 1) return;
        //  dispatch for EventEmitter
        _dispatchEvent(keys);
    }

    const getStore = () => return {..._store};

    //  watch - which key of the store to watch
    const createUseStore = (watch) => {  
        //  purely for rerendering purposes  
        const [dummy, setDummy] = useState(false);  
        const rerender = useCallback(() => setDummy(v => !v), [setDummy]);  

        useEffect(() => {  
            const eventHandler = keys => {
                //  Don't rerender if property to watch are not part of the update keys
                if(watch && !keys.includes(watch)) return;
                rerender();
            }
            EventEmitter.on(_evName, eventHandler);  
            return () => EventEmitter.removeListener(_evName, eventHandler);  
        }, [rerender, watch]);  

        //  only updates when the above event emitter is called
        return useMemo(() => {
            //  return watched property when watch is defined.
            if(watch) return [this._store[watch], this,updateStore];
            return [this._store, this.updateStore];
        }, [dummy, watch]);
    }
    return [createUseStore, updateStore, getStore];
}

A lot is going on here, but all for the functionality to be able to only have state updates when the 'watched' property is updated. For instance if the store was initialized like



{
    foo: "bar",
    fee: "fi",
    fo: "fum",
}

and a component was like



export default function myComp () {
    const [foo, updateStore] = useMyStore("foo");
    return <>{foo}</>
}

This component will not be updated by



updateStore({fee: "newFi", fo: "newFum"});

but only when 'foo' is updated, which is one of the main functionalities that I wished to implement when I set out on this bizarre journey.
A lot more functionality with a class based approach is done in the github repo mentioned above so check it out if you're interested.

Conclusion

I don't know about you, but when I started to create my own version of a personalized state management library, creating new functionality for my global state was simply enjoyable - something I rarely experienced while fiddling around with redux, possibly yak shaving my time away. But jokes aside, for most use cases doing this is the pure definition of 'reinventing the wheel', so please implement and try out at your own discretion - a fun side project without heavy reliance on global state is a scenario I would personally recommend.

My React takeaways (2020 April~August)

joon — Wed, 05 Aug 2020 18:24:29 +0000

Multi-API fetching React project structure with profuse usage of Redux

The original outline

The site is not finished yet, with a lot of tedious work left consisting of parsing and displaying blockchain transactions, but the general structure which I had envisioned at the beginning of working on the project is pretty much visible, plausible and most importantly criticizable.
~~Here are the dos, donts, trys and takeaways.~~ So this was the original intent of writing this, but it just ended being a bunch of random tips and takeaways that I amassed while working on this project.

Do - learn how to use RxJS.

But only after you realize that RxJS is truly a god-send in writing readable, maintainable, concise multi-asynchronous code. The project I was working on was I believe to be a really rare specimen of a project, where using RxJS could drastically improve DX(Developer Experience). Simple projects where asynchronousity is not too abundant should work wonders with fine-tuned custom hooks to suit your needs. I admit that I probably haven't even scraped the surface of the true power and paradigm-shifting utility of RxJS, but a bare understanding and skim through the operators was enough for me to realize that learning RxJS was like learning React after just using javascript.

Try - Managing all APIs, routes and retrieved data refining functions in a separate location/file

const refiner = {  
  default: new Map(),  
  ...getInitStatePerChain(new Map()),  
};  

_.each(_.keys(chains), v => (refiner[v] = new Map()));  
const {  
  REDUX: {PERIODICS, DATA},  
  DB,  
} = consts;  

//  /status  
const statusProps = ["block_height", "block_time", "total_validator_num", "unjailed_validator_num", "total_supply_tokens", "bonded_tokens", "total_txs_num"];  
refiner.default.set(PERIODICS[0].name, data => {
    //  pick values and refine
}

//  .....
//  a lot of refiners
//  ....


export const apiRefiner = (chain, name, data) => {  
  if (!_.isMap(refiner[chain])) throw new Error(`CRITICAL - chain ${chain}'s refiner is non-existent`);  
  const refinerFunc = refiner[chain].has(name) ? refiner[chain].get(name) : refiner.default.get(name);  
  if (!_.isFunction(refinerFunc)) throw new Error(`CRITICAL - default refiner function for ${name} is non-existent`);  
  return refinerFunc(data);  
};

If I had to pick the one thing that I tried out that probably increased the most productivity, it was this.
Manage all routes in a config file, manage all data refining by defining a map, and mapping the route to a refining function which is used to refine all data retrieved from said refiner. This method has several pros and minimal cons.

Pro - Using the same API in multiple places couldn't be easier(Modularizing the whole thing and calling the API using a custom hook turned the whole process into a single line of code + defining values in the config)
Pro - No need to use postman or any other API displaying tools(mostly), it's all nicely tucked inside your refiner file
Pro - API related logic apart from using the data gets completely detached from your components/containers
Con - initial setup takes some time

Actually using it would look something like this in a custom hook

React.useEffect(() => {  
  if (empty(key) || timestamp !== 0) return;  
  const targetUrl = `${consts.ENV[chain].api}${dbObj.route(key)}`;  
  simpleGet(targetUrl)  
      .then(res => {  
          // console.log(res);  
          sort(res.data).desc(v => v[idKey]);  
          const refinedData = apiRefiner(chain, dbObj.name, res.data);  //  refiner
          setData(refinedData);  
          const docs = _.map(refinedData, v => makeDoc(v, v[idKey]));  
          db.lazyBulkPut(docs);
      })  
      .catch(ex => {  
      console.warn(`error during fetchToDB - ${targetUrl}`, ex.message);  
      setError(true);  
      });  
}, [key, setData, setError, data, chain, timestamp, db]);

which leads to the next takeaway.

Hooks are awesome. I recommend migrating and never looking back.

The one thing that I found inconvenient was not having a componentShouldUpdate and ErrorBoundaries.
But after getting used to the 'proper way' of using useEffect(which I frequently stray from btw), and almost compulsively wrapping everything that I can get my hands on with useCallback or useMemo, missing componentShouldUpdate became pretty much trivial. As for ErrorBoundaries... well let's leave that as a con :)

Do - take care of object reference equality & in-equality

So a certain component was rerendering way too many times even before it had any kind of value. Turned out I had given it a default value of {} which was initialized somewhere else, resulting in a new object every time, thus causing the rerender. Object reference in-equality.
Ever since that experience, I created the following constant in my consts.js file, and in scenarios where initializing to an object was needed, I simply used that instead.

consts = {
//  ...
MISC: {  
  DEFAULT_OBJ: {},  
  DEFAULT_ARR: [],
  }
//  ...
}

Do use Reselect

On a heavily populated, memoized component with a useSelector hook, try console.counting inside the useSelector.
In my case, I saw the number shoot up to 80 before any content appeared to be painted which forced me to learn reselect. It took its toll, but to no regrets. I realized it was pretty much the 'memoized refiners' for selectors.
One thing that I felt was somewhat uncomfortable was that it was recommended in the reselect docs to pass parameters to reselect via redux, forcing me to create a new store that just handled variables I needed to pass. But still worth the hassle.

A neat real-time wrapper component

import React from "react"; 
import {interval} from "rxjs";

const source = interval(1000);
export default function RealTime({value, generator = () => null}) {  
  const [, updateState] = React.useState(true);  
  const forceUpdate = React.useCallback(() => updateState(v => !v), []);  

  React.useEffect(() => {  
  const subscribe = source.subscribe(() => forceUpdate());  
  return () => subscribe.unsubscribe();  
  }, []);  
  return <>{generator(value)}</>;  
}

Another reason to use RxJS. Make the generator do some kind of calculation that changes in time, and voila, you have a component that is real-time, and will be in sync with all other real-time wrapped components.

Switch css with js instead of React if possible and plausible

export default function () {  
  document.documentElement.style.setProperty("--bgHeaderColor", "linear-gradient(to right, #272538, #35305e 81%)");  
  document.documentElement.style.setProperty("--chainNameColor", "#ffffff");  
  document.documentElement.style.setProperty("--color-main", "#9c6cff");  
  document.documentElement.style.setProperty("--bgDashImage", "var(--bgDashCosmos)");
  //    ...
}

Define variables in your scss / css and change the values using javascript to switch themes / change appearances. Memoize the jsx and you've saved a rerender from repainting the entire component.(Memoizing with accurate dependencies works as well, but this method is so much more straight-forward and easy)
Example in React

const [smallSearch, setSmallSearch] = React.useState(false);  
React.useEffect(() => {  
  if (smallSearch) document.documentElement.style.setProperty("--searchHeight", "47px");  
  else document.documentElement.style.setProperty("--searchHeight", "0px");  
}, [smallSearch]);

AFAIK, this method takes much less energy than removing and adding elements to the dom.

Dont - over-cache data

Apart from extreme scenarios - which I thought mine was - high-intensity data caching takes too much time compared to the productiveness of the output. Since I was handling blockchain data which basically means fetched chain data will pretty much never change, it felt perfectly sane to try shoving every bit of data in a DB and checking and retrieving the data from the DB if it existed before attempting to fetch.
I believe the costs far out-weighed the results. It is ultra-difficult, forcing you to build different custom hooks for all kinds of asynchronous scenarios. In hindsight, it might have been worth it if I was well versed in RxJS, but attempting the feat with mostly custom hooks was not my Sunday cup of tea.

Hopefully, this helps someone. Cheers.

What I learned in the past 3 months regarding development

joon — Mon, 30 Mar 2020 22:20:58 +0000

I must admit - the title is a tad bit too ambiguous.
But it needed to be, since I wanted to write various things on dev.to on multiple occasions but simply was too busy.
It's 5am after an almost 9 hour coding streak at work.
My first open-source project is now close to being production-ready.
It's about time.

(Me from the future) This one is about CSS and developer mindsets

Update on my take on CSS

Last year on December, I cooked up a rather controversial post which went rather viral(about 20x more views than all previous posts combined) on how I deal with CSS, because - well frankly enough - I was too bad at it to realize how much I sucked. I was pretty much a perfect example of the Dunning-Kruger effect.
Yet after replying to one too many comments that I'm comfortable to admit, and trying out multiple methods thanks to the most helpful people(I tried scss, tailwind), I reached a couple of conclusions.

Use SCSS

This one is mandatory. Just pros, no cons.

Use a post-css compiler to make all your classes have different names according to filename and random strings at the end

Projects using CRA will probably need to eject to make this work(or use this) but it just makes your life so much more comfortable. A downside that I'm feeling these days is that it makes your build css substantially larger when coupled with scss and a not too optimal coding style.

Use classnames

import React from "react";  
import cn from "classnames/bind";  
import styles from "./template.scss";  

const cx = cn.bind(styles);  

export default function(props) {  
  return (  
  <div className={cx("template-wrapper")}>  
  test  
  <div>testtest</div>  
  </div>  
  );  
}

This snippet is literally how I start writing all my new components.(I use it as a live template)
I find it to be the perfect balance of DX and optimization.
But...

There's no answer

It's really up to you. I tried tailwind, and honestly I believe it could be a better alternative to the way I CSS my project.
But what really made me shift from using styled components to a scss + classnames approach was the fact that it was the approach taken by the legacy project I was given the task of maintaining.(And obviously I weighed out the pros and cons and decided it to be the best choice in my current situation)
There IS no answer. If that project was written in tailwind, I'm pretty certain that's how I'd be CSSing right now.

If you are by any chance in the same shoes as I was 3 months ago - trying to find the optimal way to write css and as a result barely getting any work done - pick a method and just go with it, refactor when you really feel the need. A close deadline always helps.

Developer mindsets

I had two jobs before my current one. Both previous jobs had problems of their own, and after 3 months(surprisingly the longest I've stayed at a single job), I am some-what truly content with my environment and would like to share some things that I heard, felt, agreed, learned from seniors or experience.

I'm an optimization freak(I think most of us are deep down inside). I love making load times shorter, and creating gimmicks that enhance UX.
One day I was feeling really proud about myself that I was able to create a new page rather quickly because I had compartmentalized my code effectively for reuse. I told that to a senior developer.
His answer was pretty much this in a nutshell.

Anyone gets good/better/faster at development given time - it's about how well you understand WHAT is needed in a project that makes you a good developer.

Let that sink in. It's not about what you can make a difference by optimizations and code structure - that should be a given. It's about the visible differences apparent to the user/client. Every single decision on every bit of code should be made with this at its base.
Which sets the scene for the next one.

Coding is decision making. Try to take into account and know as many variables as possible

In essence, this is obvious. Well, EVERYTHING is decision making to be blunt.
It's the gravity of making the right decisions based on as much information as possible that I realized was important.

One day I was lost in a train of thought, wondering what was the best method to optimize fetching data from the server. I felt that the implemented methods was putting too much strain to the backend so I was considering ways to cache already fetched data. My mind was strolling through even setting up a browser DB such as CouchDB. This wondering took more than 4 hours of my time searching through the best practices and looking for references of other projects that had faced a similar situation. After I finally made a decision, I asked my CTO on how much strain the server will be able to take. It turned out that the number of requests I was trying to reduce was almost meaningless and would save probably a few dollars a month with thousands of users.
What I was trying to fix was simply not cost-effective. I ditched the entire thought process and decided to carry on making more features in an instant. Lack of understanding on backend maintenance costs resulted in the loss of hours of productive thought processes / searching.

It's constant estimating and comparing in your mind, about what kind of approach will bring out optimal results with the time you commit. As a result, the next one comes along.

Investing time in order to be in good terms with your co-workers/people you work closely with pays off exponentially

And I mean exponentially. But there is a tipping point where time investment becomes less and less effective. This point is

when he/she/you can take constructive work-related criticism without hard feelings, and both parties feel comfortable in doing so.

If you can take constructive work-related criticism, awesome. But making sure that your co-worker can give you that criticism when they feel it is needed is a completely different matter.
This varies too much according to one's personality, so I won't go down this rabbit hole. But I find this to be one of the key factors in work efficiency, multitudes higher than being able to optimize code effectively.

Well, I'm completely knackered after typing this out.
It's 7am and I should really get some sleep.
I began writing this post as a dev log for what I learnt about React and front-end developement.
I think I committed way too much writing about developer mindsets.

Hope I didn't sound too cocky. Any form of feedback is always welcome.

Cheers.

PoS based blockchain study notes - CosmosSDK, Tendermint

joon — Wed, 08 Jan 2020 06:14:27 +0000

This post is just what I ended up mashing into my keyboard while studying from various sources(references are at the end just read those for a deeper understanding) in order to understand how Cosmos SDK, tendermint and PoS blockchains work. A basic understanding of how blockchain and PoW(Proof of Work) works is needed to understand this post.
Personally I recommend watching this youtube video by 3brown1blue if you lack the above level of understanding.

Cosmos SDK

Open source framework for multi-asset public Proof-of-Stake(PoS) blockchains or PoA(Authority) like Cosmos Hub. Generally for application-specific BC(BlockChain)
Point is interoperability with other BC
Framework to build secure BC apps on top of Tendermint(pBFT system distributor?)
Capabilities-based system, you can better reason about the security of interactions between modules
Default consensus engine is Tendermint Core. Currently the most and only mature BFT consensus engine. Currently the gold standard for PoS systems
Can be built using composable modules. Sort of like the NPM eco-system.
Secure.
Already used to build a lot of stuff. Thus proved with a market.

Blockchain architecture

In essence, BC is a replicated deterministic state machine.
Deterministic -> A given state will end in the same final state if replayed the same sequence of transactions.
Tendermint handles the replications, devs just have to define the state machine.(responsible for propagation and ordering transaction bytes)
Tendermint needs Validators, validators are responsible for adding blocks of transactions to blockchain. The next validator is chosen by the consensus algorithm to be the next validator. Block is valid if more than 2/3 of the validators signed a prevote and precommit to it. + all transactions must be valid.

Tendermint

BFT(Byzantine Fault Tolerant)-> basically a system that can still work even if some nodes or a part of a system malfunctions or decides to act maliciously
TenderMint -> middleware that takes a state transition machine and replicates it on many machines.(Sharing the slate?)
State machine is connected to underlying consensus engine using ABCI(Like a rest API?, gives methods that have Requests and Responses), which can be built using any language, thus flexible.
Can choose among multiple frameworks. Cosmos SDK is most widely used. Lotion for javascript.
ABCI allows devs to swap the consensus engine of app-specific BC. Only Tendermint is production-ready.
Devs can tweak framework or consensus engine if they feel the need.
Devs can explore the full spectrum of tradeoffs + design choices
Automatic execution of code is possible.(Logic triggered on the beginning and end of each block.
Performance, security is better.
Sovereignty -> one of the major benefits. Stakeholders of the application have full control over the entire chain. Community will not be stuck if a bug is discovered. Has freedom to choose how it will evolve.(Unlike PoW BCs)

Application-Specific Blockchains

Radically different development paradigm -> customized blockchain to work on a single application, devs can make design decisions required for application optimization. Increase in sovereignty, security, performance

Smart contract

Software that is designed as an automated self-enforcing contract, it triggers a certain action after predetermined conditions are met.
Concisely, lines of code that execute a specific function once certain conditions are met.(if… then… statements)

Drawbacks of smart contracts

Lack flexibility, certain features are simply not implementable(Like automatic code execution)
Built on the same virtual machine, thus restrain performance. When virtual machines are removed, benchmarks show 10x performance.
Limitation in sovereignty.Ultimately superseded by the governance of the underlying blockchain. Bugs will screw your life :)

Gas and Fees

gas -> how much computational resources a Tx(transaction) consumes.
gas prices -> How much a user is willing to pay for a unit of gas.
fees -> how much in fees the user is willing to pay in total.
Ultimate value of the fees paid = ceil(gas * gasPrices)
Validators decide whether or not to include a transaction in their block by comparing the given or calculated gas-prices to their local min-gas-prices. Tx will be rejected if gas-prices is not high enough. So users are incentivized to pay more.

Mempool

Every full-node that receives a Tx sends ABCI message CheckTx to app layer to check for validity and receives a response. If it passes checks, it is held in the node’s mempool(Pretty much a list of transactions unique to each node).
Waiting area for all pending transactions. Waits to be included in a block. Higher fees make a transaction processed faster

pBFT

Practical Byzantine Fault Tolerance
Aims on working even when there are malicious nodes operational. Only works if the maximum number of malicious nodes are not greater or equal to one-third of all nodes in the system.
Client sends request to primary node -> primary broadcasts request to all secondary nodes -> primary + secondary nodes perform the service and send reply to client -> request is served successfully when client receives ‘m+1’ replies from different nodes in the network with the same result. ‘m’ is number of maximum faulty nodes.(Request, pre-prepare, prepare, commit, reply)
[Limitations]
- Only works when number of nodes in the distributed network is small due to communication overhead(increases exponentially with every extra node)
- Susceptible to Sybil attacks(one party controls many nodes)
Tendermint uses pBFT + DPoS(Delegated PoS)

ABCI

Application Blockchain Interface(Interface like REST but communicates between application and Tendermint)

Cosmos explorer

https://www.mintscan.io/ (Disclaimer - I am affiliated to cosmostation)
Clicking through the site helps understand the above concepts to some extent(Not sure if it's the best site, any recommendations in the comments will be a great help)

references

https://docs.cosmos.network/master/
https://www.binance.vision/glossary/smart-contract
https://docs.tendermint.com/master/spec/consensus/consensus.html
https://www.geeksforgeeks.org/practical-byzantine-fault-tolerancepbft/

I front-end and hate CSS. Here's how I deal with it

joon — Sun, 15 Dec 2019 13:41:53 +0000

(Edit) - read the comments afterwards, I now strongly believe that this post is flawed thanks to the awesome community and I now find that there is more value in the comments than the post.

TLDR; use styled-components. If you suggest otherwise, read the post and fight me in the comments ✊

I'm a React front-end web developer with back-end origins(node, express, mongo). So naturally(for me), I dislike CSS. It doesn't feel intuitive(to me) and as someone who loves structuring databases and making queries efficiently, my passion for React hooks was a real pain since I needed to CSS in order to front-end properly.
As a result, I always required a so-called 'publisher'(not sure if such a position exists in other countries, but it exists in South Korea, basically an HTML/CSS specialist). But I was forced out of my 'no-CSS-zone' when I became the sole full-stack developer(part-time) for a startup because I forgot I don't CSS.

By the way, this method probably only works if the designer you work with supplies the design via Zeplin(which I expect to be most designers). If that's not the case, I'm afraid dark days are ahead of you my CSS-hating-comrade - I don't have answers.

So here's the gist - use Styled Components. Unless a large portion of your project's CSS is already set, I don't see an edge case when you shouldn't - and I'm not kidding. I thought about it for 3 days before I started working on my project(I wanted to CSS as less as physically possible) and tried using reactstrap+bootstrap at the beginning. Ditched everything and now I do everything with styled-components.

Here's why.

Why styled-components?

This is a page I'm working on(yes some naming conventions have not been kept but I'll fix that in the future)

The next screenshot is one without styled-components(and also a project that was terrible in terms of DX(Developer eXperience))

And I literally had to search for a snippet that didn't look terrible(yeah this is the decent one)

Before you ready your pitchforks - I agree with you, it's not the best code.
The point is readability, which influences DX, which ultimately leads to better UX(quoted from Tejas on his spectacular talk at React conf 2019)(because you spend more resources on meaningful coding)

I'm not a visual person and have difficulty picturing visual things in my mind. Yet as the person who wrote the code in the first screenshot, just scanning the names of the components I can literally visualize how it looks like.

Finding the component which I have to edit is so much easier and the code is myriads more straight forward.

The pros of using styled-components are listed on their website, so have a read and try to convince me to use something else in the comments. I'm still in my early stages if you succeed I am definitely willing to switch.

As for the part where I said you need Zeplin - it has all the CSS. Just flex all the components for responsiveness and set min-width. If you hate CSS enough to not have studied flexbox like me, finish this game and you'll be set to begin straight away(it did for me)

And that's how I deal with CSS. 😄
Thanks for reading, hope you get something out of this post.

The future of React

joon — Thu, 05 Dec 2019 12:17:24 +0000

I have a confession to make - the title was a clickbait(obviously)
I don't have the darnest clue to what the future of React will be and even if I (thought I)did, I'm pretty certain that whatever I have to say about the subject will be wildly inaccurate or irrelevant.
This post is about what I felt and imagine to be the future after watching and re-watching the first 4 hours of React conf 2019 day 1, through the eyes of a react developer still in his early stages.

HARDER

and more difficult to enter larger companies if you start small

Concurrent mode, lazy loading/code splitting, progressive hydration, loading components according to the user's mouse location etc etc.... sounds amazing.
The amount of optimizations that these stuff allow are quite literally mind-blowing. I can imagine webpage interactions being possible in less than a quarter of the time it initially took if used right.

But will this be done easily?

I'm pretty sure I'm not alone about this, but getting used to webpack configurations itself was not really a stroll in the park. Fiddling with webpack config files almost felt like a different field in web development itself - we all know it's crucial and something worth studying... yet without the right guidance and templates, it's a load of trial & error and ripping your hair out at why the hell some loader won't bloody load.[insert gif expressing frustration]

And the above optimizations, feels like the same thing - except it requires a higher level of expertise and possibly has to be applied differently per project.

As a result, large companies with a substantial amount of users will probably study and adopt these optimizations methods ASAP. In the long run they will have their own templates for said optimizations and have blazingly fast websites. But relatively small companies will probably not consider doing so unless something does it easily for them.

This is already probably true, but the skill sets required to work as a dev in a company will possibly vary even more according to the size of the company you used to work at - new development paradigms could arise that are suited for these types of optimizations. As a result, switching between smaller and larger companies could become more difficult.

Of course, everything is just a mild imagination and it might turn out the React team does an awesome job in making all the optimization methods really straightforward to apply. I haven't tried the experimental feature so I don't really know myself.(Any feedback in the comments will be greatly appreciated)

But take a look at typescript. This is my experience in working as a React dev in South Korea, but small companies generally don't bother despite the obvious benefits of using typescript. I agree on not using typescript if your website will take lets say... less than 2 weeks to code and don't plan on scaling at all. Or if your sole purpose is to make a quick MVP, I understand the choice to neglect typescript. But the reality is, most small scale companies don't - yet they expect to jam-pack the website to the brim with features and plan on using the code base for undefined periods of time.

It's a sad reality, but I do not have high hopes of it being that much different in the optimization standpoint with these amazing new features.

We need to invest more in DX

(AKA use typescript and GraphQL)

Tejas's talk was outstanding in every aspect I can think of. I highly recommend watching at least just this part of the react conf. You will inevitably obtain a powerful urge to study GraphQL and typescript.
I'm not joking, click on the title and go watch it. It's worth every minute.

If you'd rather just reap the benefits, check this out - Restful-react

Anyway, the talk was a true and living representation that DX ultimately lead to good UX, and you can really feel your productivity increasing if you had such an environment. It's quite remarkable.

Set your DX well - UX will follow. Reduce meaningless discussions by using typescript, GraphQL, end-to-end type safety, tab tab tab, no time-wasting searching through API docs or guessing games. That's the gist of it.

Wrapping up

React(hooks) is amazing, and it just keeps getting better.
There I said it.

Useful/practical tips and tricks React/js - part2

joon — Wed, 27 Nov 2019 14:37:54 +0000

63 reactions and 2 comments deserves a part 2(part1). Apparently my life was worthwhile after all.

Before we begin, José Muñoz introduced a 'monad' method in the comments of part1, which I just used today and consider as a better alternative than tip 2 on part1. Appreciation was due. Thank you José, you made my day :)

Also, I've added the 'beginner' tag because I certainly wish I knew these when I was a beginner(not that I'm not anymore).

Let the tips begin 😄

1. [React] console logging inside jsx

I think most of us have faced the scenario where we wanted to check the variable or state of something inside jsx. Like the following scenario -

const myJsx = (
    <someComponent>
        //  nested in god knows what
        {_.map(something, v => (
            <AnotherComponent someProps1="something" props2="else"/>
        )}
    </someComponent>
)

This works

const myJsx = (
    <someComponent>
        //  nested in god knows what
        {(() => console.log("hey this one works"))()}
        {console.log("this doesn't work and is probably what you tried before :)")}
        {_.map(something, v => (
            <AnotherComponent someProps1="something" props2="else"/>
        )}
    </someComponent>
)

True, about 1 minute of coding will suffice for a log function, but when you want a quick working solution, the above is the fastest workaround(I think)

2. [JS] a ===1 && a ===2 && a===3 && a===4 .... actually I think I saw a post with the same title on the bus

Long story short, use lodash or utilize arrays.

const aFunction = a => {
    if(_.every([1,2,3,4,5,6], v => v === a)) // or _.eq(v,a)
        console.log("check all of them")
    if(_.findIndex([1,2,3,4,5,6], v => v === a) !== -1)
        console.log("check for at least one of them")
    // for multiple custom conditions
    if(_.every([v => condition1(v), v => condition2(v)], func => func(a))
        console.log("wrap these up in a couple of functions and you have a lodash v2.0. Try making one, it's worth it")
}

3. [JS] when you're not bothered to use typescript but need simple checking

Too trivial for an explanation.

const isReq = () => throw new Error("missing params");
const aFunction = (a=isReq(), b=isReq()) => {
    console.log("please be a useful function");
}

yeah I'm probably running out of ideas...

4. [Redux] Yeah, it's not react but they're an iconic duo anyway - the ducks proposal

If you're not doing so already, use this file structure for redux(link), thank me later.
Simply put, you don't need to keep 3 files open to add a single action to redux anymore.

5. [JS] About randomizing... anything

search this and you probably get the following code snippet

Math.round(Math.random() * (max - min) + min);

Well, that works, but I prefer these. Honestly, it's up to you. It's pretty much why you need lodash.

_.random(min, max, false) //    pick integer in range, false=>true for floating point
_.sample(myArray)         //    pick a single value from array
_.sampleSize(myArray, n)  //    pick n values from array
_.shuffle(myArray)        //    returns the array shuffled(Fisher-yates shuffle - TLDR; pick randomly until all picked)

A mix of these coupled with effective use of the map function and you can conquer the world.

Wrapping up

I wanted to be as concise and on the point as possible with a slight sprinkle of witty remarks. Apparently I was too concise or I've forgotten whatever I was so keen on giving back to the community.
I sincerely hope you got something out of this post despite it being quite elementary.
I'm a recently 'converted' front-end react dev that used to code back-end situating in Seoul, Korea. Nice to meet you too.

Useful tips and tricks React/js - part1

joon — Sun, 24 Nov 2019 17:44:53 +0000

Hi all. This is my first post. I wont bore you with introducing myself. I'll leave that at the end if you're interested.

Let the tips begin 😄

0. [React] use hooks if you're not using them already

Just added this because I realized you might not be. Personally I'll refactor a project of 2mb to hooks if I it was written using class components. But then again, who am I to judge? Skip this post until you embrace the power of hooks.

1. [React] useState like useReducer - selectively

I actually saw this one scrolling through react posts in this community, except the post used it like it was nothing - while I felt like I struck a gold-mine and applied it to my everyday coding habits immediately.
A bit of background info - useReducer is (in my humble opinion) pretty much a wrapper for useState to make sure you don't end up setting multiple states and inducing multiple rerenders at the same time like the following

//  imports etc...
//  ...
const aFunction = (var1, var2, someCondition) => {
    if(someCondition === "something") {
        setAState(var1)
        setBState(var2)
    } else {
        setAState(var1)
    }
    //  you get the point
}

I love the smell of pointless multiple rerenders

useReducer nicely wraps up the above code to make sure both can be done in a single rerender.
But we have to define action types, and a reducer and all that stuff we're sick of doing in redux, for every case of useState. And it starts to feel a bit bloaty and botherish when you want to reduce a single rerender. So here's the gist.

//  imports
//  ...
const [reducerAlt, setReducerAlt] = useState({});

const handleState = vals => {
    if(vals.isReducer === true && _.isObject(vals.action)) {
        if(vals.action.type === undefined) throw new Error("action type is not defined")
        const valsCopy = {...vals, isReducer: undefined, action: undefined};
        switch(vals.action.type) {
            // do reducer things with valsCopy we're not bothered to and use it to set state.
        }
        return;
    }
    setReducerAlt(prev => ({...prev, ...vals}));
}

//  nice and simple
const aFunction = (var1, var2, someCondition) => {
    if(someCondition === "something") {
        handleState({aState: var1, bState: var2});
    } else {
        handleState({aState: var1});
    }
}

Not sure how well I wrote that code because I wrote it straight from markdown, but you'll probably get the gist of it. Use it like a reducer when needed, simply overwrite the state with values if not bothered.
Yes this method is error-prone but I'm sure we can all add our error-handling by ourselves without any problems... right?...

2. [React, but also JS probably] Ternary operators are tempting but not really readable. Switch cases take too many lines. So?...

I'll just throw this here. My jaw dropped as well when I found this was possible. So many places I have to fix now.

const aSwitchCase = gotItFromSomewhere();

return (
    <>
        {
            {
                case1: <Component1 />
                case2: <Component2 />
                case3: <Component3 />
                case4: SomeFunctionThatReturnsAComponent()
                case5: "yeah anything it's an object and the 'aSwitchCase' is referencing the property"
                "undefined": () => throw Error("Havent' really tried this one but I think it'll work maybe? Please comment if it doesn't I'll delete this.")
                "null": () => throw Error("ditto above")
            }[`${aSwitchCase}`]
        }
    </>
)

Just a quick note that I believe ternary operators are awesome as well and work fine as long as you're using it with a boolean. But the above example is in my opinion infinitely better if you find yourself doing something like this

const something = fromSomething();
return (
    <>
        {something === "a" ? <a /> : something === "b" ? <b /> : something === "c" ? <c /> : undefined : undefined : undefined}
    </>
)
//  yeah it's usually longer and much more unreadable. But this alone is difficult to read which proves my point.

or this

const something = fromSomething()
switch something {
    case "a":
        return <a />;
    case "b":
        return <b />;
    case "c":
        return <c />;
    default:
        throw new Error("well not infinitely better I agree");
}

When it comes to code-readability the final snippet might be more 'readable'
but for someone like me who loves forcing as much logic as possible in a single line as long as it's 'readable' - this method was a god-send.

[React] 3. I'm not affiliated to the guy in the video or the company or absolutely anything but....

If you're interested in optimizing React and have no difficulty understanding British English,
watch THIS.
I scrolled through and read several posts for about 2 weeks on optimizing react on devto, but this video was pretty much better at everything and more informative at the same time. Personally I'd choose watching the video again over a comedy skit - it was that funny(to me)

[JS] 4. Why you should use modules like lodash

I'm a big fan of lodash. But I didn't use to be. Until this happened.

const somethingAmazing = (var) => {
    if(typeof var !== 'object') throw new Error("not an object");
    // do stuff
    return "did stuff"
}

somethingAmazing(null); // not a bloody error

Turns out 'null' is an object. (Obviously why js is so popular)
Might look like a simple error, but if that is nested inside multiple components, whisks through redux and you only get weird errors that seem totally unrelated because your whole logic counts on 'var' being NOT null - this could take hours to debug if JS and the universe is trying to screw you over(as always).
Just use libraries like lodash if you care for your sanity.

const somethingAmazing = (var) => {
    if(!_.isObject(var)) throw new Error("not an object");
    // do stuff
    return "did stuff"
}

somethingAmazing(null); // yes error

Wrapping up

I was planning on writing at least 5 tips that I picked up, but I'm too tired(it's half past 2am). Maybe I'll return with a part 2. Who knows. Hope you got some useful stuff from this post. Cheers - keep coding.

PS Any feedback is greatly appreciated and will 'possibly' motivate me for a part 2.