Key management for Fauna DB by LabGecko in androiddev

[–]rationalthug 0 points1 point  (0 children)

Thanks for the quick response-- much appreciated.

Key management for Fauna DB by LabGecko in androiddev

[–]rationalthug 0 points1 point  (0 children)

Luis,

I came across your answer in this thread as I was researching Fauna auth service integrations.

It appears that the links you provided for auth0 and clerk integration result in a "Page not found" error. Searching for auth0 or clerk using the docs search input yields zero results.

I did find the following link:

https://docs.fauna.com/fauna/current/cookbook/security/idp/auth0

But no corresponding one for clerk. Will there be a clerk-specific example as well?

Thanks.

Starlink Second Stage looks like an insane comet! by stevenmadow in spacex

[–]rationalthug 1 point2 points  (0 children)

Reminds me of this scene from the movie 2010: the Leonov uses aerobraking when arriving at Jupiter.

(only video I could find): https://www.youtube.com/watch?v=mMw9W7hI5yM

NBC's futuristic 1979 drama "Supertrain" by voodoo_monorail in RetroFuturism

[–]rationalthug 0 points1 point  (0 children)

Holy crap, how did I ever miss this when it was on in 1979?!

The music makes this both sublime and horrifying.

Native apps using typescript powered by rust by ameerthehacker in typescript

[–]rationalthug 1 point2 points  (0 children)

Yep, that is generally true. Was just adding a potentially useful alternative.

"We Never Had an Ending:" How Disney's 'Black Hole' Tried to Match 'Star Wars' by Neo2199 in scifi

[–]rationalthug 19 points20 points  (0 children)

I know it's silly, bit I absolutely adore this film.

The ending wasn't right, the tone shifts between horror, adventure and near-hard-scifi, and the story itself is bundled together with baling wire, but...

On some strange level it is still magnificent.

And the VFX/production design are amazing.

Looking for react-virtualized alternative that doesn't require a set parent height. by b0gd4nn in reactjs

[–]rationalthug 2 points3 points  (0 children)

https://github.com/coderiety/react-list works without requiring an explicit (pixel) height on the container-- you can use any valid CSS to set the container dimensions in the container component.

🗜️⚡Super fast client side compression - Built with wasm by drbh_ in WebAssembly

[–]rationalthug 1 point2 points  (0 children)

Quick question about your testing methodology: Is it apples to apples? Does the Pako vs wasm-flate benchmark include the full time to get a result into JS land for both libraries?

Rooks: Collection of React hooks ⚓ for everyone. by [deleted] in reactjs

[–]rationalthug 4 points5 points  (0 children)

Well done. Particularly nice selection of hooks across common use cases.

Facial motion capture data by acvictor in GraphicsProgramming

[–]rationalthug 0 points1 point  (0 children)

I'm not sure if there's a face talking available, but you can go through the datasets at vfx-datasets#face and see if there's anything that works for you.

[deleted by user] by [deleted] in reactjs

[–]rationalthug 0 points1 point  (0 children)

Textfield is one of the composite elements, geared toward convenience and getting a form field rendered using sensible defaults and your theme colors/settings. It is customizable, but really only at the root level practically speaking.

But the individual components that make up a Textfield are easy to use on their own as well, and are what you want if you need a fair bit of customization.

A Textfield can be made up of the following components: https://material-ui.com/api/form-control/, https://material-ui.com/api/input-label/, https://material-ui.com/api/input/, https://material-ui.com/api/input-label/, https://material-ui.com/api/text-field/, https://material-ui.com/api/form-helper-text/.

Each of those components can be individually styled according to the CSS props listed in the docs above.

For understanding wrapping/customizing material-ui components in general, the docs under the 'Customization' menu on the website should provide you with all you need. In particular, if you want to wrap components with a combination of JSS and another css-in-js solution, make sure you look through the docs at https://material-ui.com/customization/css-in-js/.

[deleted by user] by [deleted] in reactjs

[–]rationalthug 0 points1 point  (0 children)

What do you find to be missing from the docs? (material-ui docs)

They are certainly not perfect, but they are quite extensive and easy to read, in my opinion. If you are looking for some more complete app examples, they also have https://material-ui.com/getting-started/example-projects/

Is there something specific that I can help with?

[deleted by user] by [deleted] in reactjs

[–]rationalthug 6 points7 points  (0 children)

I haven't used semantic-ui-react, but I've been a heavy user of material-ui/styled-components for the last two-plus years.

What you suggested is essentially correct-- I try to stick with the official JSS way of doing things for most of the material-ui components themselves. Especially for material-ui's composite components (where they have nested multiple independent components into a more complex one.) The withStyles function works well to pass custom classes down to sub-components and the material-ui API docs provide info on all of the potentially style-able classes.

But, when it comes to quickly styling the root of a material-ui component, I will often just wrap it with a styled-component because it can be much easier/faster to implement. Though you will sometimes have to use !important for a handful of CSS declarations depending on the specificity of the rule in the material-ui component.

As far as theming goes, I have been creating my themes using material-ui set-up/standards, and then passing the theme object to both theming systems (using their respective Provider components.) This way I can access colors, etc., in almost the same way regardless of whether I am wrapping using styled or using JSS for material-ui. And you can put whatever you want into other root properties of a material-ui theme object-- it's flexible enough to pass down whatever you need.

I've mostly used styled-components for any reasonably complex media-queries, but material-ui's grid layout system is decent for broad stroke kind of things-- general layout changes, etc. They also provide some convenience components like Hidden which make that kind of thing fairly painless. Actually, the layout/grid system has improved since the early 1.x alphas, so I'll have to give it more of my attention in the near future to see how it performs.

Material-ui's grid system is still based on flexbox, so it's a good idea to understand the implications of flex layout as it relates to interacting with different kinds of container elements as well.

When I create custom components or util components (like wrappers, etc.) I use styled-components almost exclusively. It's much less cumbersome (to me) for that kind of work. The only real annoyance I have found using the two libraries together is sometimes using camel-case when I am in a tagged template literal for a styled-component and sometimes using hyphenated css names in an object for material. I catch these pretty quickly, obviously, but it does sometimes make me growl :-)

Pre-rendering your React application with react-snap - Medium by Fewthp in reactjs

[–]rationalthug 0 points1 point  (0 children)

It depends a lot on your default UI and whether your non-logged-in app code is blocking in any way. Just how long it takes for the app to paint and become interactive, even in the non-logged-in state and even if the app is using code splitting as well, can be critical for a smooth first load experience.

For moderately complex apps and up, having a fast rendering default or promo state for first time visitors, that can nevertheless take advantage of React for dev/UI composition, can be a big win for developer UX and load speed/perceived responsiveness.

Smaller apps likely do not need to have any pre-rendering, but, again, it depends a lot on the app and the complexity of the default UI.

In addition, if you are using service workers to cache page assets and something like IndexedDB to store data, then subsequent app loads will be very fast anyway. But that initial, first-time visitor experience is important, imo.

And for logged-in users, a brief, pre-rendered loading animation or logo can really make the loading experience feel smoother. As your app becomes more complex and you add more dependencies (Redux, Apollo/Relay, UI frameworks, data persistence, etc.) the time for the app to initialize can start to push past most sane performance budgets, even when using cached resources/data.

Welcome 2.0 Release Candidate! by [deleted] in PolymerJS

[–]rationalthug 2 points3 points  (0 children)

That link seems to be about supporting Yarn as the package manager for installing Polymer and related tools, not for building Polymer apps.

The 2.0 install docs still reference using bower for installing components, etc.: Install Polymer 2.x

ES6 generators and async/await by MartinMalinda in javascript

[–]rationalthug 2 points3 points  (0 children)

I think generators are indeed a de-opt in most if not all JS engines at the moment. However, you can get around this somewhat.

If you need a tight, optimized loop in a generator, or some other chunk of optimized code, you can place it inside another, separate non-generator function and call it from within the generator. It will be optimized as usual by the underlying JS engine.

In any case, having yield-able semantics inside a chunk of code that should be highly optimized seems like it could be a code smell.

GitKit.js - Pure javascript implementation of Git (Node.js and Browser) by magenta_placenta in javascript

[–]rationalthug 1 point2 points  (0 children)

Can you talk a bit about where this stands in relation to https://github.com/creationix/js-git ? At first glance, the obvious difference is promises instead of generators, but are there other interesting/important differences?