SSR + CSS Class Names Duplicated? August 17, 2019
Posted by kevinbe71 in Development, React, TypeScript, Uncategorized, Web Development.Tags: css modules, React, ssr, storybook, theming, TypeScript
add a comment
Over the last couple of weeks I’ve been messing around with a new React-based project: trying to get Storybook + Theming + React + SSR + TypeScript all playing nicely together.
I first started with NextJS and tried to get Styled Components working with it and Storybook. After running into too many problems I abandoned NextJS. The final straw being Styled Components type definitions that weren’t working well and I had to revert back to a pretty old version of the type defs which wasn’t acceptable.
Next I started looking for some kind of starter project (I decided that it was better if I had full control and not leave too much to behind-the-scenes “magic”). I found a good one and started tweaking it to my needs. I thought everything was working nicely- Storybook worked with theming and I started moving the “test” components into the main app (with SSR). This is where the title of the blog post comes into play…
Although the component styling had worked flawlessly in Storybook I started to see issues when it was running through SSR: the app would initially render well and then, within a split second, it would mess up the styling. When I inspected the DOM I saw that a class name that was meant to be applied to only one element was being applied to both the parent and child div.
I started to blame CSS Modules because I hadn’t used them enough to know what could/could not be done with them. However, it wasn’t CSS Modules that were the problem, because I could tell that it was rendering correctly and then being “corrupted” somehow. At first I didn’t recognize it as that and suspected that it was just either the SSR version of the app or the client-side version that was rendering incorrectly. I disabled SSR and it worked perfectly: so it must be the SSR configuration, right? Wrong.
Ultimately it turned out to be a mismatch in the index.tsx on the “client” side and the serverRenderer.tsx. I had inadvertently added an extra “level” to my router config! I added a MainLayout component to one of these files but not the other. So, in essence the server was rendering one hierarchy (missing MainLayout) while the client was rendering a different one. React tries to reconcile the differences and it seems that it doesn’t know how to clean up the CSS class names properly so that results in duplication of class names on the wrong nodes! It seems that the virtual DOM doesn’t always get it right.
TypeScript Timeline October 13, 2018
Posted by kevinbe71 in Angular, Javascript, node, React, TypeScript, Uncategorized, Vue.Tags: Angular, angularjs, Javascript, node, React, release timeline, timeline, TypeScript, typescript releases, typescript timeline, Vue, vuejs
add a comment
TypeScript is a very cleverly architected solution to adding types to Javascript. The team behind it managed to create something that still allows the flexibility of Javascript while remaining 100% compatible with it (Javascript files are TypeScript files to the compiling and there’s even the allowJs option if you’re too lazy to rename your pure javascript files to .ts).
One of the best decisions they made was to support structural typing instead of requiring a strict type match (like many static languages do, e.g. Java and C#).
That said, as I’ve read more news about key companies adopting TypeScript I’ve always wondered how this matched up with the actual release timeline. So, I went to the effort today to put that together. The screenshot below is a very low resolution image, so it is purely meant as a thumbnail (you can click on it to navigate to the screenshot I took):
However, if you’d like to interact with the timeline, you can use this URL: TypeScript Timeline
React – Organizing Imports (Part 2) February 10, 2018
Posted by kevinbe71 in Development, Javascript, React, Web Development.Tags: best practices, Code organization, organizing code, React
add a comment
In my last blog post ( https://berryware.wordpress.com/2018/01/20/react-organizing-imports/ ) I mentioned these sections:
// externals
// state
// action creators
// consts/enums
// interfaces
Here are 2 more sections that can be added:
// components
// selectors
This will help you get a better idea of the type of categories you can introduce yourself… let me know in the comments if you have ideas for other categories.
React – Organizing Imports January 20, 2018
Posted by kevinbe71 in Javascript, React, TypeScript, Web Development.Tags: best practices, Code organization, Javascript, organizing code, React, TypeScript
1 comment so far
I’ve been using TypeScript with React code for a couple of years now so I’ve learned what works and what doesn’t, so I thought I’d share a little of that wisdom…
Over time you’ll find that your application code starts to grow and grow until it starts to become a bit messy and you need to organize things a little better. If you have some “best practices” in your toolbox you can avoid having to go back and change all your old… so I’ll share this little tip that will hopefully save you some time later: how to organize your imports.
import { Action, Dispatch, Store } from 'redux';
import * as ActionTypes
from '../../shared/constants/actions/ActionTypes';
import { FSAAction }
from '../../shared/models/actions/base';
import { ShowPersonImageActions }
from '../actions/workflows/ShowPersonImageActions';
import { StateTree }
from '../../shared/models/state/StateTree';
import {
WorkflowShowPersonImagesStepAction,
WorkflowShowPersionImagesAction
} from '../../shared/models/actions/workflow';
import { FSAWithType } from '../../shared/models/actions/base';
This may seem OK to you, but there’s actually a problem we’re not seeing because of all the clutter… so let’s do a little bit of categorizing & sorting alphabetically:
// externals
import { Action, Dispatch, Store } from 'redux';
// state
import { StateTree }
from '../../shared/models/state/StateTree';
// action creators
import { ShowPersonImageActions }
from '../actions/workflows/ShowPersonImageActions';
// consts/enums
import * as ActionTypes
from '../../shared/constants/actions/ActionTypes';
// interfaces
import {
WorkflowShowPersonImagesStepAction,
WorkflowShowPersionImagesAction
} from '../../shared/models/actions/workflow';
import { FSAAction }
from '../../shared/models/actions/base';
import { FSAWithType } from '../../shared/models/actions/base';
I like to put “externals” at the top, followed by the basic building blocks in order… “state” first because that’s where we’re getting our data from (think of ordering things a layer at a time). Next we have actions and the constants/enums that are used along with them and finally interfaces. I consider interfaces as the connecting glue that pulls everything together so I put them last.
Hopefully you will have noticed something at this point: grouping things into categories may have highlighted something… we have an import statement that can be combined!
import { FSAAction, FSAWithType } from '../../shared/models/actions/base';
Obviously this technique assumes that you’ve split out interfaces into separate files etc. and a few other code structuring rules are in place, but you should get the idea of how to apply this to you own projects. Let me know if you like the idea in comments below or if you have another approach that works for you.
The Berryware Blog 