amk_

Here's one: https://medium.com/@mbaranovski/quick-guide-to-tdd-in-react-...

Extracted boilerplate from some of my libs:

https://github.com/alexkrolick/react-lib-quickstart

Want to port this to a CLI eventually, too

IMO its origins in the gaming community, and all the moderation features that grew out of it, make Discord a much better fit for open source communities than Slack. For example:

- Individuals can block and report other users

- There are tiered mod levels

- Per-community pseudonyms, but a single account makes it easier to track bad actors

Markdown support, including syntax highlighting, is actually better in Discord than Slack already, too.

If you haven't checked out an OSS community on Discord yet here are a few:

- https://www.reactiflux.com/

- https://chat.vuejs.org

- https://discord.gg/reasonml

A framework like Phoenix would be awesome. Even something more lightweight (Express-like) would be pretty handy. Clojurescript front-end, Clojure backend...

CSS-in-JS libs like https://emotion.sh make "micro-componentization" even easier - pretty much every raw DOM element can be replaced by a domain-relevant/ui-relevant component type. Then if you need to add something beyond styles like state or complex render logic, the consumers don't even know about it because the reference is the same.

Fastify is a similar project that aims to be faster than Express and adds a number of API improvements like baked-in schema validation for routes, logging, and async-by-default APIs.

Haven't used it in production but replaced Express with it in some side projects.

Since server.js is built on top of express it might even be possible to build a variant of it on Fastify instead and get those benefits as well.

https://www.fastify.io/

This would be a good checklist for anyone considering building a UI framework. This kind of thing is the reason Bootstrap & friends are so large - they do a lot for you.

I have to agree, this will create a new component type every time the function is called, definitely causing a repaint and re-render of the subtree.

The "right" way to do this is re-implement `connect` as a render-callback and then use that to create a HOC, not the other way around.

https://github.com/juliankrispel/redux-connector/blob/master...

Here's a Codepen that demonstrates which component-creation methods are safely inlineable and which aren't:

https://codepen.io/alexkrolick/pen/WZwMYW

GIF of repaints: https://user-images.githubusercontent.com/1571667/30631908-f...

Still, it isn't entirely obvious under what conditions the methods of a React Component class are going to be called. For all you know they might always be called against the instance.

Wrote about that recently: https://medium.com/@alexkrolick/writing-react-components-for...

See also: the docs

The adapter system is super interesting: https://github.com/airbnb/enzyme/blob/master/docs/guides/mig...

This might be the way to go for complex dependencies like React where APIs move in and out of the main package, or could be implemented by third parties (like how Preact can supply render and createElement in a mostly-compatible way).

It also makes clear that semver dependencies in package.json are insufficient to describe the library combinations that work in the main package.

Yeah, I wrote about it last week:

https://medium.com/@alexkrolick/writing-react-components-for...

"Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel."

I could be wrong, but I don't think a LISP macro can transform the structure of the code in the same way that the JSX pragma turns an XML tree "inside-out". For example here's the source for the Babel JSX transformer:

https://github.com/babel/babel/blob/master/packages/babel-pl...

    KHTML -> Webkit -> Blink
             \_ Safari   \_ Chromium
              |_ Epiphany  |_ Opera 15+
                           |_ Vivaldi

React is my preferred frontend library, so rather than ditch it when I needed to work with a CMS I decided to go JSX-free and write my component in plain ES2015 with Preact's hyperscript/createElement syntax. I thought I'd write up a few tips and a demo widget to show how it works.

Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel.

BTW the Codepen version of the post has much better code formatting: https://codepen.io/alexkrolick/post/react-without-a-build-st...

Some thought-provoking stuff in that one.

Just VSCode with the ESLint plugin and this theme: https://marketplace.visualstudio.com/items?itemName=jdinhlif...

I used https://getkap.co/

Just recorded this GIF of typing out a function with the added visual cues:

http://imgur.com/a/LQVV2

IMO it's comparable to a WYSIWYG equation editor vs looking at raw LaTeX - conceptual errors pop more.

exactly, and the !== != forms are also correspondingly adjusted

I really like the giant, triple-line === ligature for JS in Fira Code. Makes it super-obvious when you are doing strict vs sloppy equality checks.

I like how they "trick" you to engage with the video, and don't give you an option to get distracted trying to dig around the page. Normally I skip videos if I can and miss out on the high-level guided introduction.

The [video] tag would be a good warning for the sound though.

setState doesn't actually care whether you've mutated your data or updated it immutably.

Not necessarily - if something downstream is looking at the values (such as a shouldComponentUpdate check), the first mutation may cause the current value to === the next value and prevent a render. I know you called this out as an "optimization" but you don't always know what's happening inside your components, especially if 3rd party libraries are involved.

Does anyone use Clojurescript as a webapp backend instead of Clojure?

Wow, cool, you could totally make a Myst-like adventure with this.

One nitpick - on a touchscreen drag actions move the screen the exact opposite way that I'd expect (like "natural scroll" on a touchpad). The rotation detection using is cool though.

"Search everything" is a big value prop for Evernote. You can't search E2E encrypted database records without transporting them to the client and decrypting them there.

Bootstrap 3 and Foundation 5 are both really nice, mature frameworks.

Bootstrap 4 and Foundation 6 on the other hand seem to be having problems. I think part of it is that developer interest stalled with the explosion of framework-specific component libraries for React, Vue, Angular, Ember, etc.

- https://cto-security-checklist.sqreen.io/

- https://github.com/FallibleInc/security-guide-for-developers...

And there are more that have been posted here: https://hn.algolia.com/?query=security%20checklist&sort=byPo...

React supports these SVG attributes:

https://facebook.github.io/react/docs/dom-elements.html#all-...

    accentHeight accumulate additive alignmentBaseline allowReorder alphabetic 
    amplitude arabicForm ascent attributeName attributeType autoReverse azimuth
    baseFrequency baseProfile baselineShift bbox begin bias by calcMode capHeight
    clip clipPath clipPathUnits clipRule colorInterpolation
    colorInterpolationFilters colorProfile colorRendering contentScriptType
    contentStyleType cursor cx cy d decelerate descent diffuseConstant direction
    display divisor dominantBaseline dur dx dy edgeMode elevation enableBackground
    end exponent externalResourcesRequired fill fillOpacity fillRule filter
    filterRes filterUnits floodColor floodOpacity focusable fontFamily fontSize
    fontSizeAdjust fontStretch fontStyle fontVariant fontWeight format from fx fy
    g1 g2 glyphName glyphOrientationHorizontal glyphOrientationVertical glyphRef
    gradientTransform gradientUnits hanging horizAdvX horizOriginX ideographic
    imageRendering in in2 intercept k k1 k2 k3 k4 kernelMatrix kernelUnitLength
    kerning keyPoints keySplines keyTimes lengthAdjust letterSpacing lightingColor
    limitingConeAngle local markerEnd markerHeight markerMid markerStart
    markerUnits markerWidth mask maskContentUnits maskUnits mathematical mode
    numOctaves offset opacity operator order orient orientation origin overflow
    overlinePosition overlineThickness paintOrder panose1 pathLength
    patternContentUnits patternTransform patternUnits pointerEvents points
    pointsAtX pointsAtY pointsAtZ preserveAlpha preserveAspectRatio primitiveUnits
    r radius refX refY renderingIntent repeatCount repeatDur requiredExtensions
    requiredFeatures restart result rotate rx ry scale seed shapeRendering slope
    spacing specularConstant specularExponent speed spreadMethod startOffset
    stdDeviation stemh stemv stitchTiles stopColor stopOpacity
    strikethroughPosition strikethroughThickness string stroke strokeDasharray
    strokeDashoffset strokeLinecap strokeLinejoin strokeMiterlimit strokeOpacity
    strokeWidth surfaceScale systemLanguage tableValues targetX targetY textAnchor
    textDecoration textLength textRendering to transform u1 u2 underlinePosition
    underlineThickness unicode unicodeBidi unicodeRange unitsPerEm vAlphabetic
    vHanging vIdeographic vMathematical values vectorEffect version vertAdvY
    vertOriginX vertOriginY viewBox viewTarget visibility widths wordSpacing
    writingMode x x1 x2 xChannelSelector xHeight xlinkActuate xlinkArcrole
    xlinkHref xlinkRole xlinkShow xlinkTitle xlinkType xmlns xmlnsXlink xmlBase
    xmlLang xmlSpace y y1 y2 yChannelSelector z zoomAndPan

If we switch to it as a hard dependency, library consumers on React <16 will have an extra package in the bundle. If we make it an optional peer dependency, package.json becomes less reliable because we would need to check where createClass is implemented at runtime.

Is create-react-class smart enough to determine whether the version of React it is augmenting already implements createClass to prevent bundle size bloat?