Posts

react hooks: closer to a reactive library

react hooks: closer to a reactive libraryWith the introduction of react hooks, the library is closer to a reactive library, perhaps closer to the original intent of react. I use react hooks via my library scalajs-reaction.One of the problems with react today is that it sometimes hard to reason about, hook functions (the new component hotness instead of classes) are not pure functions. State, ref, and other types of hooks mutate state underneath in the react “fiber” sub-system.Hooks is closer to the more ideal approach. In the ideal approach, a little bit of the DOM is updated when the data dependencies that create that part of the DOM change. For example, if a text object changes, then a div or p should change in the DOM. You can do this with hooks, but it looks like (taken from the react hooks website):functionExample({suffix}){const[count, setCount]=useState(0);return(<div><p>You clicked {count} times</p><button onClick={()=>setCount(count +1)}> Cl…

seems complicated but shouldn't be

seems complicated but shouldn't bePeople wonder why some things seem complicated, for example, in react. React is fairly unprincipled in its use of effects, but it works for most people and it helps build better UI.The new react hooks use functions instead of classes to define components. That’s good. But as DanA points out, functions are different than classes and the differences can be subtle.Since the concept and language of effects has not been around react for long, and the language is still evolving, you get into fairly big piles of goo when it comes time to explain things around effects.Here’s an example article of where the language of effects, say as leveraged from category theory, might help be more precise: https://overreacted.io/a-complete-guide-to-useeffect/Having said that, it is true that category theory vocabulary sounds scary and Dan was probably right in not using that language and instead used examples to illustrative his point, but you wind with alot of goo tha…

copying scala.js linker artifacts after linking

copying scala.js linker artifacts after linkingThere have been a few requests for a plugin to copy the scala.js linker artifacts to another location after the linker has run. While you could set the output path for the artifact to a different location, you may want to have the artifacts generated into the standard location then copy it to somewhere else to provide better compatibility with existing tooling.Ad-hoc ApproachHere’s one way to add a copy process to a specific sub-project:def copyTask(odir:String)={lazyval copyJSOutput = taskKey[Unit]("copy scala.js linker outputs to another location") Seq( copyJSOutput :={ println(s"Copying artifact ${scalaJSLinkedFile.in(Compile).value.path} to [${odir}]")val src = file(scalaJSLinkedFile.in(Compile).value.path) IO.copy(Seq((src, file(odir)/ src.name),(file(src.getCanonicalPath()+".map"), file(odir)/(src.name +".map"))), CopyOptions(true,true,true))}, fastOptJS / copyJSOutput :…

user experience, scala.js, cats-effect, IO

user experience, scala.js, cats-effect, IOThis is not a complicated snippet but I wanted to ensure I remembered it.When creating a UI, say react for browsers, you will run into the “fetch” data problem. When you fetch data, you typically have a component that performs the fetch and acts as a cache for the result. The fetch component renders a child and passes along the data that was fetched (or the fetch state, etc.).Even with the upcoming react suspense mechanism that will make this a smoother user experience, you may have a flash of a “loading” indicator that shows for a moment before the content is fetched from the server. If the flash is too fast, it is visually disruptive. A shimmer mechanism for the UI my also not be the answer.Similarly, if the fetch request takes too long, you will want it to time-out and show an error message that the data could not be fetched or whatever is appropriate for feedback in your application.Generally, I use cats-effect IO for my main effect.Scala.…

programming languages, not sure javascript's ES* all make sense

programming languages, not sure javascript's ES* all make senseWell I was just thinking the other day about javascript and its pros and cons.Its clearly an interpreted language with a simple syntax. That makes it easy to learn.However, there have been alot of changes using the ES* process. Each version adds some new functionality, sometimes a little sometimes alot. Sometimes just enhancing a few APIs sometimes making large changes, such as adding module systems.I was doing some work in scala.js the other day, along with nodejs+express+mssql+typescript for the backend. I could have written the backend in scala.jvm but there was no compelling reason to do that as there was some json manipulation and I find js to be easier to use when json is involved. You can avoid alot of encoders/decoder type coding when using scala.js and that just makes it much easier (whether you are in scala.js or typescript).But I did notice that even with instant node+express reload using “nodemon” (restarts…

env variables with node, express and typescript

env variables with node, express and typescriptIf you need to manage environment variables better for express, node and typescript web services, you have a few choices.Define a default set of vars using an “environments” file and fallback to those while using an optional user provided file.Add fallback values in .ts code.Don’t add fallback values and error out of require variables are missing.The standard thinking is that if you have environment variables that hold secrets or a file of environment variables these should not be checked in at all because you should use the production method of setting environment variables e.g. a container can set environment variables using container methods. You can always setup a separate, restricted VCS repo to hold secrete information that only production admins can access. Hence, .env files should only be used for non-production, say dev and test, and not checked into VSC.The default package to use is “dotenv”. dotenv reads a .env file at runtime …

typescript, node, express: adding ts properties to Request

typescript, node, express: adding ts properties to RequestIf you use typescript with node+express and you add some context to the Request parameters, you need to adjust your Request type to reflect the additional properties. Otherwise, your IDE may flag any accesses to these properties as errors.Let’s assume you will add an “environment” property to Request. You’ll want to have that property available to typescript.I always have a types folder sitting around in my “src” directory that has a types.d.ts file. You do not need to put this into a type roots folder and change tsconfig.json. Here’s my adjusment:import{ Request, Response, Send }from"express"import*as env from"../interfaces/Environment"// add our addition to Requestdeclare global {namespace Express {interfaceRequest{ environment: env.Environment }interfaceResponse{// holds original Response.sense, used for overrides. sendResponse: Send }}}