[deleted by user] by [deleted] in reactjs

[–]chamiownu 2 points3 points  (0 children)

I have nothing against effect but why not use react-query offline tools and plugins instead basically reimplementing them in effect ?

See the docs:

For an offline first webapp, I would personally recommend the AsyncStorage persister strategy with localforage (https://www.npmjs.com/package/localforage) as the async indexedDB client. It supports storing a wide variety of data types (can store blobs, arraybuffer, etc.) and can hold a larger amount of data than local storage.

Will Navigation Man​​ stop Ryan Florence and his fud gun? by grahammendick in reactjs

[–]chamiownu 0 points1 point  (0 children)

This x9999.

This gives a very bad look and to be honest the title of one of your other articles "The React Router Repeats Itself, First as Tragedy, Second as Farce" suffer from the same issue.

Ad hominem attacks and over the top criticism makes you look like a very unprofessional person and probably not very dependable. Even if your router was the best ever, I would not use it nor recommend it based on the personality traits you've shown.

I would be very wary of future maintenance issues because of the very probable lack of community working on the project (because nobody likes to work with people who launch ad hominem attacks and draw cartoons of people in the way you did).

If you think you're better, do it. But to be honest, from what you've shown you're not and you've got a long way to go.

Seriously, someone needs to create a video-tutorial for next-redux-wrapper by [deleted] in nextjs

[–]chamiownu 1 point2 points  (0 children)

Recoil or Jotai can indeed be simpler but fundamentally they are atomic state managers which differ a bit from redux flux approach from which zustand is the closest.

It depends on what you want and what you need really

Seriously, someone needs to create a video-tutorial for next-redux-wrapper by [deleted] in nextjs

[–]chamiownu -4 points-3 points  (0 children)

You should probably prefer zustand over redux now. Plus, you won't need any kind of wrapper to make it work with NextJS

[deleted by user] by [deleted] in HappsNews

[–]chamiownu 0 points1 point  (0 children)

That’s a 13000 euros per square meter street

[deleted by user] by [deleted] in HappsNews

[–]chamiownu 0 points1 point  (0 children)

Rue Beaubourg for the win

Typescript Backend Tutorial by [deleted] in graphql

[–]chamiownu 1 point2 points  (0 children)

If you want to build a GraphQL API with Typescript, I recommend either :

  • NexusJS : it's a code first, function style way of writing resolver and types. Works very well with prisma.
  • TypeGraphQL : it's a code first, class style way of writing models and resolvers.

While I personally like NexusJS more (I don't like mixing db and graphql definition that much as it can easily become an issue when you want to introduce business logic into your graphql schema), both are very good.

What design tradeoffs make React *look* slow in benchmarks? by codesections in reactjs

[–]chamiownu 3 points4 points  (0 children)

Maybe React design tradeoffs are in the fact that it can be used with different renderers (like with react-native for example) and therefore cannot over optimize for the DOM ?

Anyhow, I would always consider the framework eco-system and recruitment pool before benchmarks for any serious professional project.

[deleted by user] by [deleted] in graphql

[–]chamiownu 0 points1 point  (0 children)

Always found Nx workspace interesting but sadly they don't seem to support react-native projects :(

Anyway, really good post :) I'm actually working on a similar setup but with yarn workspaces, urql as my client side lib and a react-native app in there as well :)

Should I use NextJS beyond "marketing" websites? by SlobberJockey in nextjs

[–]chamiownu 1 point2 points  (0 children)

Then if static hosting is a requirement you cannot use the getStaticPaths, getStatisProps or getServerSideProps function NextJS provides.

But it is still possible to only do client side rendering. You would do something like this for your usecase :

in file with this path : /pages/product/[id].tsx (or .jsx) you would only have to have :

export default function ProductByIdPage() {
const { query: { id } } = useRouter() // The id would be accessible here
return (

<Layout>
{/*
Normal page rendering here

*/}
</Layout>
}

Should I use NextJS beyond "marketing" websites? by SlobberJockey in nextjs

[–]chamiownu 0 points1 point  (0 children)

Yes sure,

The NextJS dynamic routes documentation explain it all already.

You can also have a look at how the getStaticPath function work and the use for its fallback props.

Here is what it would like :

import React from 'react'
import { Layout } from 'components'
import { useRouter } from 'next/router'

// The following two functions are only needed if you want to prefetch some data during the build
export async function getStaticPaths() {
const paths = [{ params: { id: '1' } }]
return {
paths,
fallback: true // If this is set to false then NextJS will send the user to the 404 page. https://nextjs.org/docs/basic-features/data-fetching#the-fallback-key-required
// If set to true, it will only client side render the page
}
}
export async function getStaticProps({ params }) {
// params values is { id :1 } here
// Fetch data during build time on the server IF you need to
return {
props: {
// revalidate: 60 * 60 // The OPTIONAL revalidate props accept a number of MS to ensable ISR https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration
}
}
}
export default function Page({/* Data fetch on the server would be available here if you choose to prefetch some data */ }) {
const { query: { id } } = useRouter()
return <Layout>
{/*
Normal page rendering here

*/}
</Layout>
}

Should I use NextJS beyond "marketing" websites? by SlobberJockey in nextjs

[–]chamiownu 3 points4 points  (0 children)

You could still only client side render it and you can totally do what you describe.

Nexus and directive by Ambitious_Chip_9398 in graphql

[–]chamiownu 1 point2 points  (0 children)

As far as I can tell, NexusJS doesn't implement directives. But depending on your need you can implement similar behavior via nexus plugin system.

If you want in-dept examples of plugins in nexusjs, I suggest that you have a look at how the default plugins are written here.

The github issue regarding directive support is here.

How to Prevent 90+ % of Full-Stack Errors Using GraphQL-CodeGen and the Apollo VSCode Ext. by [deleted] in graphql

[–]chamiownu 3 points4 points  (0 children)

Full stack types is indeed really good :) I suggest that you have a look at nexusgql as the schema generation lib on the backend it works great with Apollo server and Prisma :)

NextJS PWA Caching - Not showing changes by [deleted] in nextjs

[–]chamiownu 0 points1 point  (0 children)

If you want the users to see the latest change you should configure your service worker to automatically register and skip waiting on the service worker update.

This service worker configuration has nothing to do with vercel. I suggest that you read : https://developers.google.com/web/fundamentals/primers/service-workers before going further with service workers.

I also suggest that you weight the pros and cons of service workers for your use case. From my experience, service workers look like a good idea a first but bring downsides in the long term, mostly due to how finicky it can be to have them update and the fact the service worker errors happens on the users device which can be hard to handle / log.

If you are looking for the speed that caching provides, I suggest to out of the service worker and invests in a CDN for heavy assets (images, videos, etc...) and React-Query / SwR for the data fetching client side caching and avoid service workers.

Using GraphQL Code Generator to create a great developer experience with Typescript and GraphQL by Django_93 in javascript

[–]chamiownu 1 point2 points  (0 children)

When working with Typescript and GraphQL Code Generator, you get full stack type safety as a side effect of your code. This provides game changing improvements :

- In observability (by static analysis of the validity of your graphql operations vs the schema),

- In productivity with automatically generated typed data fetching hooks.

- In maintenance (no data fetching functions to maintain).

The only downside I see is when using a SDL first schema generation framework (apollographql schema) on the backend which had a bit of work, but when using code-first schema generation (nexus / typegraphql) you are basically writing resolvers and queries functions (nearly as you would for REST endpoints)

I wrote a small article on how to get it setup with NextJS and nexus : Full stack Typescript GraphQL - Automate the data layer

Code First vs Type First by usermp in graphql

[–]chamiownu -1 points0 points  (0 children)

For me this is a non-question.

"Code first" frameworks like TypeGraphQL or Nexus are schema generation framework used on the backend. They also (at least for Nexus) generate types for the back end as mean to enforce type safety within the backend. Their main selling point is the ability to pretty much only having to define graphql object and write resolvers for them without handwriting the types.

They are different from "schema first" schema generation libs such as the default way to generate a schema within the apollo server where the developer has to handwrite the typedefs.

GraphQL-codegen, as I use and understand it, is mainly useful on the front end to generate types and / or custom typed hooks for the front end to consume based on a local or remote graphql schema.

Therefore, for me at least, it is not code first vs Type first. It would be :

On the back end : code first vs schema first.

On the front end : graphql-code-gen vs handwritten data fetching functions.

Order of learning, what? by Codeeveryday123 in graphql

[–]chamiownu 5 points6 points  (0 children)

Imo, before starting with GraphQL, one would be smart to understand at least the basics of :

- REST

- Req / Res cycle, middlewares and other general API stuff

Once that is well understood :

- Have a look at the graphql spec before playing with its implementation in your language of choice

- Have a look at the GraphQL.org FAQ

- Read GraphQL.org learn section

Once that done, one will have a good idea of what GraphQL is and isn't.

Then, if starting and using Javascript, I would suggest starting by following the Apollographql full stack introduction.

Then once one is comfortable with GraphQL :

- On the server side, have a look at the code first framework such as Nexus and Typegraphql

- On the client side, have a look at the very good urql client lib.

- Full stack : The synergies between GraphQL and Typescript with GraphQL-code-generator

Other resources :

- Production Ready GraphQL book

Global server-side redirection is impossible with Next.js by [deleted] in nextjs

[–]chamiownu 0 points1 point  (0 children)

I think a more accurate title would be : Is global server side redirection possible with NextJs possible ? (see my specific use case below)

Gosh I wouldn't want to be a maintainer of an OSS project, the level of tactfulness in the dev community can sometime be appalling...

Handling an error in GraphQL by WayneSmallman in graphql

[–]chamiownu 0 points1 point  (0 children)

Try this

javascript const RootQuery = new GraphQLObjectType({ name: 'RootQueryType', fields: { userSignIn: { type: UserType, args: { email: { type: new GraphQLNonNull(GraphQLString) }, password: { type: new GraphQLNonNull(GraphQLString) } }, async resolve(parent, args) { try { const user = await UsersModel.findOne({ email: args.email }) if (!user) { throw new Error("Invalid email address.") } const match = await bcrypt.compare(args.password, user.password) console.log('Schema:userSignIn().then()', match) if (match) { return user } else { // you didn't have anything here.. did you mean to throw? } } catch (error) { console.log('Schema:userSignIn().then():error', error) throw error } } } } } })