npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

o-react-blue-typescript-not

v0.11.0

Published

Utilities for react-blue not depending on a pre-processor

Downloads

7

Readme

o-react-blue-typescript-not

This package contains o-react-blue classes that do not require source code pre-processing

It's version number is the same as o-react-blue, and both packages are intended to work together, but minimizing the burden of source code pre-processing to the bare minimum required by JSX

Any project using o-react-blue will also use o-react-blue-typescript-not, but it will probably have a smaller foot print, a faster loading time, a more simple configuration, less requirements and a much better maintainability experience

Documentation

http://o-programming-language.org/

The programs I write expect objects to have a consistent identity during the program execution, and source code manipulation utilities like Babel rarely preserve it

Probably there are a few good reasons to statically process a language like Javasccript, I just can't think of any that is required to run a js program and that it can't be achieved with dynamic, simple and executable js code

As an example, @haijindev/o-css can declare and load css in plain javascript without pre-processing, or even defining, any .css file

Fun fact, what @haijindev/o-css does, it was possible and simple to do from the very first versions of javascript, at least a decade before libraries like sass or less were conceived, but it wasn't until the release of React library that such a solution became thinkable

Yet another fun fact about the identity of objects

Here's a fun use of preserving the identity of objects during the whole existance of a program: electronic currencies

Say, 30 years ago, a system with hundreds of billions of records may not have been conceivable

Today, any regular database, even a relational database, might store that amount of records

Particularly, if the records are nothing more than sets of ids

Here's a very not sophisticated idea for an electronic currency:

  • let every coin have a unique, immutable id. A unique serial number
  • let each user have a unique, immutable id
  • let any user account be a set of unique coin ids
  • let a transaction be to move one or more identified coins from a target set to a destination set
  • let be a unique entity capable of creating new coins. Which is the same as creating new ids. No computational effort is required
  • to allow offline transactions, let be a syncronization mechanism of choice between local, distributed sets of ids and a central entity to make its conciliation

Every coin having a unique id would allow offline transactions to be valid if, and only if, in both ends of the transaction the same coins are signed as moved from a target to a destination

To sign a transaction, the unique ids of both users and all of the unique ids of the coins would be used

To validate a transaction, the destination user may query if the signature of the target ids corresponds to the ids held in that account. The query would not be does this user have enough funds to make the transfer? but, does the user account hold the concrete coins he's about to transfer?

Therefore, a user could not claim neither that he owns an abstract amount of money, nor that other user transferred him an abstract amount of money. Only that another user transferred him a concrete set of ids, and to prove it he would need to know the particular ids of the coins and to posses the correct signature for having them

In the film Superman IV, the villian works for a bank and gets rich by transferring the rounding pennies, unclaimed left-overs of valid transactions, to an account of his own

If every penny would have had a unique id, he would had get caught

I don't think a system can get more traceability of the money flow than having each coin to have a unique id, making frauds more difficult