fwouts

You may want to check out previewjs.com (disclaimer I'm the author) although it's unfortunately not getting much love or attention lately, my kids are using all of that.

Unless I completely misunderstood the post, a function that calls another function with effects will indeed be "infected". That is, unless the effect ends up being local (such as passing a mutable reference to a local variable).

Yes! They're called discriminated unions: https://www.typescriptlang.org/docs/handbook/typescript-in-5...

Here's an example: https://tseditor.fwouts.com/?t=ZXhwb3J0IHR5cGUgVmFsdWUgPSBVc...

This is now implemented. Easier than expected!

Generating random values is live now :)

Oh, I was wondering if people would ask for that exact scenario! I'll see if I can make that happen, check again in a few days :)

Thanks for the feedback!

Random values sound like a fantastic idea. It shouldn't be too hard to implement in the current codebase either. I'll add it in the coming days/weeks.

Hey! Author of Preview.js here :)

It's early days and you might find that Preview.js can be a little difficult to set up in a large, complex project (working on improving that now) but please send through any feedback on the GitHub repo or Discord server, much appreciated!

Thank you, appreciate it! :)

Hi everyone, author here.

This was originally an extension for Visual Studio Code to preview React components directly in your IDE (that's still available too, as well as for IntelliJ now).

I've since gotten feedback that it's a useful alternative to Storybook, which people often find frustratingly slow, so I decided to build a CLI version as well.

React Preview is not yet open source (I'll probably end up switching to an open core model at some point) but it's based on ViteJS (which is significantly faster than webpack). It also uses the TypeScript Compiler API to resolve types and automatically generate valid props, so you don't need to configure custom stories like you would with Storybook (although that's supported too).

You can also check out the detailed docs at https://reactpreview.com

Please let me know what you think, any feedback is a gift!

Hi everyone!

I've been working on React Preview for a few months. It's currently only available for Visual Studio Code, but an IntelliJ/WebStorm and CLI versions are also in the works and coming soon (you can subscribe to be notified at https://signup.reactpreview.com).

The plan is for React Preview to be a freemium product. The current features are all free, with more advanced paid features coming soon (e.g. integration with Storybook, mosaic of all your components, preview in multiple viewports, etc).

Please don't hesitate to send through bug reports on GitHub (https://github.com/zenclabs/reactpreview/issues) and let me know what you think in the comments!

This is a really cool idea!

A bit of self-promotion: I've been building something similar but without the visual editing, integrating directly in your VS Code editor (and soon IntelliJ/WebStorm too). See https://reactpreview.com for more info.

Direct link to the latest beta for Visual Studio Code for HN friends: https://reactpreview.com/download/releases/reactpreview-vsco...

(it's very early days, this beta isn't even a week old, so expect to find bugs)

I was frustrated with people missing emails/slack messages about GitHub pull requests.

I built a browser extension that shows a notification pop-up and updates the extension badge whenever you get a new pull request. Then I proceeded to convince my colleagues to use it.

For any Googlers out there, this is the same thing as CL Monitor, but for GitHub. I used to maintain CL Monitor back in the days (although I didn't invent it).

You can try it out at https://github.com/fwouts/prmonitor :)

I really like seeing efforts being made in this direction. For the last few years I've been using git-town.com, which works quite well but I often end up having to work around it (especially when I have diamond-shaped branch dependencies, e.g. to refactor two independent things before implementing a small feature on top). I'll have to try this instead and compare!

A colleague of mine who I value as a good tech lead recently wrote some tips based on his experience: https://medium.com/swlh/two-lessons-youll-learn-in-your-firs...

He also just published another article about quality technical communication, which I'd highly recommend both you and your team read through: https://medium.com/@tpagram/a-guide-to-improving-your-techni...

If you want visual regression testing and you use React, you can also try https://github.com/fwouts/react-screenshot-test

(disclaimer: I wrote this)

That's interesting, I didn't know about this issue.

There are a couple of solutions in this GitHub issue FYI: https://github.com/typicode/husky/issues/108

Indeed, that's why you'd want to use a solution like Git LFS to avoid bloating your repo. Basically, it only stores a link to the image, which is stored separately.

Thanks!

I'd encourage you to try Git LFS, it's a very simple extension to Git. It only takes a couple of minutes to set up if you use GitHub, and I suspect other platforms are similar :)

I'd recommend reading "The Laws of Human Nature" by Robert Greene. It talks about this.

My interpretation from the book: it's a perfectly natural feeling, but it doesn't mean you have to act on negative destructive instincts. There are ways to channel this energy into more productive behaviours (e.g. by using it to challenge yourself).

We tried writing OpenAPI docs to implement a contract-first development workflow, with the idea that backend & frontend/mobile engineers would agree on the API interface by discussing OpenAPI changes in a pull request, and only then start implementing it (on the backend side) and using it (on the client side).

This didn't pan out well, because it turns out OpenAPI isn't very easy to read, especially when you're reviewing a diff in a pull request. We didn't get the engagement we were looking for in pull requests.

We've since invested in building a simpler, human-friendly API description language based on TypeScript, which exports to OpenAPI 3. It's still early, but we've got a lot of positive feedback and quick adoption across the company (50 engineers).

You can check it out at https://github.com/airtasker/spot. Feel free to send us feedback in GitHub issues or replying to this comment :)

Google no longer uses Perforce.

https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

There's a quick manual in the README at https://github.com/zenclabs/deploy. We'll add some docs on the landing page too :)

Currently, we set up a separate Application Load Balancer for each of your deployments.

It's technically possible to share a single ALB for several deployments, but it becomes harder to manage and sharing the same ALB between dev/prod/staging for example isn't necessarily a safe design (e.g. if you run some load testing on one deployment, it should not put other deployments at risk).

Will add more docs, thank you for the feedback!

Yes indeed!

The reason CloudFormation isn't used is because it's a lot slower. It also has its own bugs, so it didn't seem like a big win: https://stackoverflow.com/questions/46280080/cannot-delete-a...

See https://github.com/zenclabs/deploy/commit/72c1fc847661a0ed0d... for the old CloudFormation equivalent :) Happy to bring it back if there's demand for it!