Blis is the audience-first platform that doesn't rely on personal data

blis

Crypto has become the darling of alternative investments, captivating the financial world with heart-stopping falls (hello 2021 and 2022) and meteoric rises (hello 2024 and the potential effects of halving). But amidst the adrenaline-fuelled rollercoaster ride that is crypto trading, many enthusiasts forget about taxation - mistakenly assuming crypto falls outside of the realms of more ‘traditional’ financial regulations. Whether you're ‘hodl’ing (holding on for dear life) or engaging in frequent trading, remember that the taxman is keeping a watchful eye on your crypto earnings. With the financial year set to close out at the end of this month in New Zealand, here’s a beginner's guide to getting it right… The Bottom Line Alas, even in crypto - the taxman still cometh, and your assets are subject to taxation under country-specific income tax rules. In simple terms, any gains or losses from your crypto investments must be declared as part of your taxable income within each tax year. Just like any other activity that you do to make a profit (such as your 9-5, running a business, trading stocks, or setting up a lemonade stand), you need to pay income tax on the profits you make. Income tax will normally apply to any ‘disposal’ of crypto – this includes selling for NZD/USD or trading it for another crypto. Income tax also applies to your income on crypto holdings, e.g. staking or yield. Although this might ‘sound’ simple, it can be complex to manage when adjusting your portfolio; for example, you may want to temporarily move your Bitcoin into stablecoin to wait out some market volatility, and then get back in. Although you have not ‘sold out’ of crypto, the tax ticket is clipped with any gains, and the question becomes (especially for high-income earners) whether it is worth 'trading' dips when this may create a 31-39% taxable event. There's No Simple Way to Say This… Rules and regulations around crypto gains vary significantly from one region to another, and it's crucial to familiarize yourself with the relevant legislation in your specific regions to ensure you’re complying. In general, however, there are some common principles that apply wherever you’re trading… If you've made gains from your crypto ventures, you're obligated to pay taxes on those profits. On the flip side, if you've incurred losses, you may be able to offset them against taxes paid in other areas, such as PAYE on your salary. It's Not All Bad News… But while the taxman may demand his due on crypto gains, there are certain situations in which you can breathe a sigh of relief… You don’t normally need to pay income tax on any cryptocurrency you are holding and haven’t sold or swapped yet. This includes purchasing crypto with fiat currency. In addition, with crypto such as stablecoins in the underlying currency, there is no price change/volatility associated with a purchase/sale, and no associated taxable event is triggered. Similarly, if you're simply hodling onto your crypto assets without engaging in active trading, you may not be liable for taxes until you decide to sell or dispose of them. Additionally, the transfer of Bitcoin between wallets, as well as gifting or donating crypto, typically does not trigger tax obligations. When it comes to taxes, ignorance is never bliss. With the crypto market booming and profits tantalizingly within reach, it's essential to remember your obligations to the taxman. Failing to report your earnings could land you in hot water with authorities. By familiarizing yourself with the relevant tax laws in your jurisdiction, staying abreast of regulatory developments, and seeking professional advice when necessary, you can ensure that your trading remains both profitable and above board.* (*We always recommend getting professional tax advice. In New Zealand, can offer sound advice.) Cryptocurrency Tax NZ

Crypto Taxes: Ignorance Is Never Bliss!

**GRAND CAYMAN, Cayman Islands, November 30th, 2023/Chainwire/--**Sui, the pioneering Layer 1 blockchain and smart contract platform created by the technology team that emerged from Meta’s Diem Blockchain project, has accelerated beyond expectations in just over six months since its mainnet launch, surpassing $150 million in Total Value Locked (TVL) according to leading DeFi aggregator . DefiLlama This key milestone, which currently places Sui within the top 20 blockchains in TVL, signifies a growing DeFi ecosystem backed by a deep pool of developer talent and a community that is strengthening by the day. In addition to its TVL trajectory, which is up over 500% since the start of September, the Sui Network has surged past $100 million in bridged stablecoins. Sui has also surpassed Bitcoin in total historical on-chain transaction count, affirming its capacity for scalability and efficiency, and underscoring the blockchain’s ability to facilitate seamless, secure, and lightning-fast transactions. The ability to process a high volume of transactions while maintaining peak network performance has supported this DeFi growth, as Sui recently set a new record for the most transactions processed in a single day by any blockchain ever. “Sui's rapid ascension reflects both the growing demand for its unique, native technology and a vibrant community that is fueling the growth and adoption of the Sui Network,” said Greg Siourounis, Managing Director of the Sui Foundation. “To reach this level of adoption within months of the network’s mainnet launch is remarkable and bodes extremely well for the future of this burgeoning DeFi ecosystem.” This level of growth is further supported by a robust network of independent DeFi projects adding value and utility for the community. For example, Cetus, a leading DEX and concentrated liquidity protocol within the Sui ecosystem, also recently achieved a significant feat by surpassing $1 billion in total transaction volume. This accomplishment underscores the depth and decentralization of the Sui Network's DeFi landscape. Builders on Sui are also prioritizing relationships and collaborations across the globe, as evidenced by the recent partnership announcement with . With roots in Abu Dhabi, the UAE's capital, and a large investment base, Hub71 supports over 260 startups, and has committed to introducing UAE-based startups to the Sui ecosystem. technology incubator Hub71 Sui's ascendancy makes it a growing force in the industry as Web3 braces itself for what many expect to be a period of high growth. With its object-centric model and unparalleled scalability, Sui’s potential for mass adoption arises from its simplicity for developers and rapid transaction processing for broader use cases. Builders, users, and organizations alike can learn more about the network by visiting . https://sui.io Contact Sui Foundation media@sui.io This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program . here

Sui Surpasses $150M in TVL, Showcasing Blistering DeFi Momentum

Get to know Caretta - a lightweight, standalone tool that instantly creates a visual network map of the services running in your cluster. Caretta leverages eBPF to efficiently map service network interactions in a K8s cluster, and Grafana to query & visualize the collected data. Scientists have long known that the turtles, like many animals, navigate at sea by sensing the invisible lines of the magnetic field, similar to how sailors use latitude and longitude. But the common sea turtle does much more than that. Turtles also rely on the Earth's magnetic field to find their way home, using the unique magnetic signature of their birth coastline as an internal compass. Turtles have effectively tamed the wilderness of the open ocean. What can be seen to some animals as an infinite unknown is mapped to the finest of details inside the head of the sea turtle. From the sea to the cloud, it’s all too easy to get lost in a typical Kubernetes cluster. Gaining a decent understanding of the inter-dependencies between the different workloads running in the cluster is a complicated task, leaving teams to work hard for impactful, actionable insights such as identifying central points of failure or pinpointing security anomalies. One approach to tackle this issue is visualization: In many ways, a K8s cluster can be seen as a geographic area, with paths and trails forged by communications between different workloads. And just as a map helps familiarize you with your neighborhood and how to navigate around it, it can help you “get around” your K8s cluster. This is part of the mission of cloud-native observability tools - no APM product is complete without network tracing capabilities of some kind, and data from these traces can help one answer those aforementioned questions. But continuing the approach from our previous post on , what if I only want a minimalistic, efficient solution? Murre So, what is the easiest way we can map our cluster? Introducing Caretta - a standalone OSS tool that does just that. Let’s dive into how it works, how it leverages eBPF technology to be lightweight and frictionless, and the obstacles and challenges we encountered on our journey to building it. The end result could be digested directly as raw Prometheus metrics, or you can integrate it into your Grafana with some of our pre-made panels: Exploring the land First thing we’ll need to figure out is how we get the network data. The naive approach would be using a sniffing tool like tcpdump to gain network observability. But that can be overkill - we don’t need to actually capture the network traffic, we just want to know it exists. As suggested above, we can use eBPF to probe just the data we need. eBPF who? If you haven’t already heard of eBPF I can tell you that people like Brendan Gregg call it an "invaluable technology" and compare it to JavaScript: was introduced in early 2014, expanding on BPF's original architecture by providing tools that allow complex programs to run directly in the Linux kernel space. OK, now you’re probably asking yourself what running the kernel space even means. Basically, it's code running in higher privileges, as opposed to running in "user space" like standard applications.  It allows the code to run very efficiently, access low-level kernel resources that would otherwise be complicated and costly (in terms of resource overhead) to access from within user space, but most importantly: it lets you observe any and all programs running in user space – which is hard to do when relying on observability tools that operate in user space themselves. This is a big thing. It’s basically a new way of equipping the Linux kernel with a programmable, highly efficient virtual machine, allowing programmers access into what was before the sole realm of kernel-developers. Observability is where eBPF shines. It allows teams to monitor their running applications with a completely out-of-band approach that requires zero code changes or R&D efforts. eBPF enables powerful advantages for observability applications by providing a faster, less resource intensive and holistic approach to gather high precision data. eBPF offers many ways to capture data from a running system. The kernel allows developers who use eBPF to attach their programs to various types of probes - places in the code of the kernel or applications that when reached, will run the programs attached to them before or after executing their original code. This diagram shows some of the probes available for eBPF: So instead of a static HTML website, JavaScript lets you define mini programs that run on events like mouse clicks, which are run in a safe virtual machine in the browser. And with eBPF, instead of a fixed kernel, you can now write mini programs that run on events like disk I/O, which are run in a safe virtual machine in the kernel. eBPF Image from ebpf.io/what-is-ebpf Starting with the basics Working on this project, I was inspired by - a nifty tool to calculate statistics and information of TCP lifespans, using only a single eBPF probe. The thing is, the kernel already does half of the job for us as it maintains information, such as throughput, for each socket. By probing the tcp_set_state kernel function, tcplife is aware of the active network connection and is accessible to data the kernel maintains for them. Beside having minimal footprint, another advantage of probing specific kernel functions is covering all possible data flows - compared to probing a bunch of possible syscalls the application might use, such as read() or recv(). When application-level context is unnecessary, “sitting” close to the root of the tree lets you cover its branches more easily. tcplife Sounds great - but we’d still be missing something. tcp_set_state is called when, obviously, the state of the TCP connection is being set. For example, when a server starts listening, or when a server-client connection is established, or when a connection is closed. But TCP connections can go long without changing their state, and relying on tcp_set_state will keep us blind to them. We set out to look for an additional probe that can help us complete the picture. Even then, we find eBPF useful to explore the linux TCP stack. Tools like or can be used to understand the flow a network packet is going through when it’s processed and compare different functions to see how “noisy” each function is. Searching for data probing locations consists of a constant trade-off between being too nosy and being blind, and we’re looking for the sweet spot in the middle. stacksnoop stackcount In our case, we found the function suitable for our needs: tcp_data_queue This function is called as one of the final steps of , the function used when receiving packets in the ESTABLISHED state: tcp_rcv_established So it covers the blindspot of , and is called only if all previous steps were successful. tcp_set_state Another advantage to using this function is that like , and most of the kernel TCP functions, its first argument is a struct sock object. This is a big, important kernel struct and we’ll soon dive into the advantages and disadvantages of relying on it to retrieve data, but for now we’ll say it’s convenient that both our probes share a consistent approach to the data. tcp_set_state To recap our collection mechanism - we’ll probe to observe the network sockets updating its stats in their established state, and tcp_set_state to track their lifecycle. tcp_data_queue Understanding the data As mentioned, our “supply” of data comes from internal kernel network stack objects of a struct called sock. Socks actually wrap other data structures for TCP and INET, so having them means having the data for lower levels of the connection as well. Information like the connection’s 4-tuple (source IP, source port, destination IP and destination port) can be easily retrieved from the sock, especially using the CO-RE approach. Some issues arise from using kernel internal structures. For example, instead of allocating a new sock each time, the kernel may reuse closed structs. Apparently, socks reusing might occur frequently, and if we do not keep track of socks ending and starting it can lead to collisions and disinformation. Another difficult issue for extracting the data out of the was understanding the role of our host. The sock contains source IP and destination IP, but has no information about who’s the client or the server in this connection. For new socks, we can see (in ) if it goes through TCP_SYN_RECV or TCP_SYN_SENT to understand the side of the equation it’s on; But if the connection was already established, we can’t see the previous states it’s gone through. The solution we found was examining a field in the sock struct called . It holds the maximal length of the accept queue, and is assigned as part of the listen() function of the connection. Which means, that if it is assigned a positive number, the sock went through a listen state, and therefore is a server - and vice versa. That information gives us the direction of the link and the relevant port to store. sock tcp_set_state sk_max_ack_backlog Aggregation So we figured out how to deal with those sock structures. But we’re not really interested in them - we’re interested in it at a higher level. If a client queries a server hundreds of times one after another, we’d like to address it as a single edge in the graph. So the next thing we’re going to do is aggregating what we see in the kernel probes to start counting (tuples of client, server and server-port) and their . The eBPF program will maintain a map of the sockets it observes, and a userland program accessible to this map will poll over it and generalize each connection to a link and aggregate the throughputs. We’ll run this program on each node in our cluster, and every instance of it will publish the results as to be scraped by a centralized pod. Let’s talk about the structure of our data. We basically want to have a counter for each link, which is populated by aggregating smaller counters - the ones maintained by the kernel. Sockets can come and go, so we need to keep track of the total throughput of past, closed sockets as well. Eventually, our metrics will expose the total throughput of each link observed since launching the program. That information, scraped and consolidated by a prometheus agent, can be easily analyzed with standard queries such as sorting, calculating rate, filtering namespaces and time ranges, and of course - visualizing as a network map. Below is an example of a timeseries published by a Caretta’s agent: Links Throughputs metrics As you can see, the identifiers are resolved from an IP address to the controllers owning the workloads communicating. For example, in this link we can see sending 2537 bytes to a service named Note that some of the labels are generated solely to comply with the format Grafana expects for displaying a Node Graph. checkoutservice productcatalogservice. Speaking in Kubernetes terms One thing left before publishing the metrics is resolving the source and destination of each link to the language we want to speak - our cluster’s language, with our k8s-defined names. That might sound trivial - the information should be easily retrievable using the K8s API. But again, some obstacles arise. The first and simple one was API requests overhead. Querying the API for each object we encounter, especially in the beginning of the run of the program, leads to a big amount of REST messages which simply take too much time. The solution was using a bunch of big queries in the beginning of each polling iteration and storing a snapshot of the cluster’s state. With the snapshot, we can build a mapping of the IPs used by objects in the cluster, and for each object get its ancestors in the hierarchy to consolidate the nodes of the graph to meaningful items like DaemonSets and Deployments. On the other hand, some cases are very hard to resolve. For example, Caretta doesn’t support resolution of Pods set to “host” network, as they use the node’s IP address directly themselves. Keeping track of bound ports and their processes can be a solution for that in the future, but it will make the program more complicated. Same problem occurs with traffic originated in NAT’d services arriving in other pods in the cluster, which makes it impossible to associate it with a workload given the source IP alone. We can also add reverse-DNS lookup to try and resolve external IP addresses. Putting it all together With resolved and aggregated metrics, what’s left for us is running an agent pod as a daemonset in our cluster along with a single metrics scraper. To visualize a map, we will use Grafana’s Node Graph feature - a fairly new panel in beta version. Of course, there are countless libraries to create an image of a map out of a description of relations, but we wanted to use a tool which is very much likely already installed on your cluster. Caretta is equipped with a Grafana dashboard consisting of a Node Graph panel and some PromQL witchcraft queries to adjust the data to Node Graph’s specifications. After setting Caretta as a Prometheus data source in Grafana, the dashboard will display the map of your cluster. But actually, instead of trying to explain the architecture of Caretta with words, let’s use… Caretta itself! Here’s what an instance of Caretta shows when filtered on its own namespace: As you can see, we have a Grafana instance querying a VictoriaMetrics ( ) agent (and displaying this map on its web UI); The Victoria agent scrapes metrics from caretta daemonset; And both the Victoria agent and Caretta make use of the kubernetes API exposed by the Kubernetes service. But I’m sure you've already figured that out :) Beside that, we have the Kubernetes Node itself probing the Grafana’s and Victoria’s health probes and the Grafana pulling external resources from the web. caretta-vm Gaining landscape insights Along the road, analyzing (and debugging :)) the data collected by Caretta’s agent revealed some surprising behaviors in our dev cluster. Although the main purpose of creating this tool was understanding the communications between different services, the “background” traffic caught our attention and enlightened us. Here are some examples of that usually-transparent traffic: 1. Non-container networking: A lot of the traffic observed by Caretta wasn’t coming from a pod at all, but from “normal” processes running on the nodes themselves. In our case, it was the kubelet process itself next to aws-specific agents. This communication shouldn’t come off as a surprise, as it is essential to controlling and running the cluster, but seeing its intensity clears some mist surrounding it. 2. Control-Plane networking: like how the kubelet is a “transparent” component in the node, the control plane is a cluster-wide “transparent” component. We all know the control plane and its role, but have you ever wondered where it actually resides? The answer to this question is vendor-specific, but for AWS and GCP the control plane is actually hosted in servers outside of your cluster managed by the vendor itself, bridged to the cluster with dedicated interfaces. 3. Endpoint with no targets: continuing with the control plane, the API server is exposed via the kubernetes service in the default namespace. But because, as mentioned, the API server doesn’t actually reside in any workload inside the cluster, and this endpoint merely forwards the traffic out to the control plane. Final Words Mapping the inter-dependencies between the different services running in the cluster is a complicated but critical task. Unlocking this rare type of information can help developers, devops and SRE teams get a much clearer view into their production K8s clusters. eBPF is shaking the foundations of how we understand and experience observability. What was once almost impossible to get can now be obtained in just a few minutes on huge complex clusters running hundreds of different microservices, and Caretta implements exactly this modern lightweight approach. The next tools that will rule the K8s eco-system will be efficient, ad-hoc and fast. Teams just have too much on their plate to work hard for critical data. Caretta is open-source, and we’d love to get your feedback and contributions. Head over to our GitHub , create an issue with a bug or a feature request, or drop your thoughts on our community slack Previously Posted on groundcover's blog by Udi Rot, Founding Engineer

Navigate Your Way to Production Bliss with Caretta

David Copperfield: Chapter 33 -  Blissful

From the Brink of Suicide to Bliss: How Hormones Destroyed and Saved My Life

My Journey to Achieving DevOps Bliss, Without Useless AWS certifications

SaaS has matured dramatically over the last 5–10 years, to the point where teams are directly adopting the software they need to do their jobs without any oversight. The sheer number of high quality products solving all sorts of business needs has driven the fast rise of SaaS. In fact, our own data across 500+ customers shows this is dominating across all business functions. proliferation in SaaS This explosion in SaaS adoption can introduce new challenges to business. These are important issues and questions that affect the entire organization, including: : Is the new vendor that marketing chose SOC 2 compliant? Which vendors have access to sensitive information? Are our employes following basic account security best-practices? Security & compliance : Who’s reviewing the SaaS spending on a regular basis, now that it’s a significant line item in the P&L? Budgeting : How do you evaluate and compare vendors, or manage the renewal process? Vendor management : How do you make sure new employees have access to the apps they need to be productive? Or that former employees don’t have access? People operations and workflows In the past, the IT team typically addressed these challenges, but now the picture looks a lot more informal — chaotic, even. In many cases, finance is left to discover unchecked spending issues, while engineering teams are on the front-lines of security and compliance challenges that can put the organization’s reputation and business on the line. Meanwhile, people ops teams are left with onboarding and offboarding employees onto the right technology. SaaS has made IT everyone’s job, but much of that job today is purely reactive. If organizations aren’t feeling the pain of SaaS chaos now, they will be soon. Solving for SaaS chaos requires a collaborative effort, rather than a single person, team, or point solution. Organizations need to engage with IT and Security, Finance, HR, team leaders, executives, and more. We created to give these teams real-time visibility into SaaS app usage and spending, serving a single source of record for across the entire organization. Eric Paley at Founder Collective, whom Aaron White and I have had the pleasure of working with for two companies, likes to say that we’re “creating the operating system for IT teams of the future.” Blissfully SaaS management Since launching out of private beta last fall, we’ve now worked with over 500 customers to solve pain points across their organizations. And we’re excited to keep building. To continue investing towards our vision of blissful SaaS management, we’re announcing a $3.5M seed round, led by Hummer Winblad Venture Partners (HWVP), and joined by HubSpot, Founder Collective, and a collection of great angel investors. Mitchell Kertzman, an experienced operator and General Partner at HWVP who led the round and is joining our board, said, “We think having the right platform to manage the proliferation of SaaS apps and vendors is the foundation for today’s modern IT, and we’re excited to back Blissfully to tackle that vision.” This funding will accelerate our vision of powering a new model of IT management, purpose-built for the SaaS world — helping us make continued investments in our product, growth, and team. HubSpot, a Blissfully investor and SaaS leader serving over 40,000 small and mid-market companies has seen the industry’s rocketship growth first-hand. CEO Brian Halligan added: “The widespread growth of SaaS across companies of all sizes is a leading indicator of the market need for Blissfully. We believe the Blissfully team can solve the problem of SaaS chaos, giving businesses critical insights into their application stack.” SaaS has changed the way teams work for the better. Now, the approach to IT management has to evolve along with the way people work today. Blissfully’s ultimate goal is to give companies a new level of visibility, helping them get a handle on SaaS chaos and make smarter, more informed decisions. You can learn more and sign up for free at Blissfully.com. Originally published at www.blissfully.com on August 9, 2018.

Blissfully Announces $3.5 Million Investment to Power the Future of IT

Apollo is the best solution for managing remote data with a client cache. But if you are already using Apollo (or another client cache like Relay), the question is: What should you do about the rest of your client state? React’s new context API (available in 16.3 or as a polyfill) has opened up new possibilities for dealing with app state. At , we’ve been trying to find that blissful state that combines the data from the server, component state, and the app state, which hasn’t always been smooth. OK GROW! App state is tiny I became interested in Redux after watching Dan Abramov’s seminal talk at ReactEurope. After I’d learned the basics of Redux, I began looking for information on “advanced Redux.” But that brought me face-to-face with the problem with Redux for users: Every tutorial I found turned out to be implementing a client cache. You would learn the three or so ways to do async with Redux and then implement those async actions to work with your Redux store. But Apollo’s client cache already does all of that. It has all of my loading and error states handled, it deals with optimistic updates, you name it. So what’s left to manage? Apollo The answer, as it turns out, is very little for most apps. Most of it should just live in components. React What about centralizing to Redux for better testability? I agree that this makes testing very easy, but I have two problems with it: The whole point of having a component system is for encapsulation. React allows you to put state into your components so that when you are working elsewhere, you don’t have to think about what’s happening in that component. As soon as you try to separate that functionality, you have keep two things in your head, the component and the state (which is now probably in a separate file, so you need more buffers open). Not only that, but there is also risk that somebody else (never you!) would be tempted to grab that state from a different component. It breaks encapsulation. I’ve heard of developers making their entire app out of functional components with all state coming from Redux. Hey, I had a “let’s use all functional components!” phase too. But having a global store bypasses the top-down data flow and makes your app harder to reason about. Also, that’s a lot more code! Removing state from components feels un-React-y. Some of this movement stems from the fact that testing components has been pretty awkward for a long time, but I think we can solve that using tools like (more on this in a future post), or possibly a new tool like . React Test Renderer Cosmos There are apps that will really benefit from Redux, so I’m not saying not to use it. But in my own work, I have not been able to justify the overhead once Apollo took over remote data synchronization and caching. What state is left to manage? If you put most of your state into components and have a client cache, what’s left? Almost nothing. In one app, I had only a single global state variable to manage. But I tried managing it directly with the old Context API, and that convinced me that app-wide state is still a problem worth solving! Here are some things I think legitimately belong in app-wide state: Top-down data propagation runs into a roadblock when you hit a routing boundary. Of course you’ll pass some params to dependent routes, but passing shared state is a recipe for disaster. Just use app state instead. State that needs to be shared between routes. Sure you could put it in your root component and pass it down, but why? As an aside, I think a case can be made to store current session information (e.g., is the user logged in) in state even though you can also do that with Apollo. State that is used all over the place. In the last app I worked on, we tried . The logic is compelling: Since you already have a nice library to query and update values in the database, and since most of your data will already be in that format, why not just store your app state the same way? Then you have one way to do things, and you can use the existing reactive query components to update UI elements regardless of whether the data is local or remote. Apollo Link State To be fair, Apollo Link State totally works, though I ran into some sharp edges on what was then a new addition to Apollo. The real problem is that the way you produce and consume local app data just doesn’t match the pattern of remote data. Queries for remote data tend to be specific to one part of your app and don’t repeat much. The queries are intentionally verbose to clarify the relationship between the client and server, and they may reside in their own files and may have options for optimistic updates, updating based on mutations, etc. They also make extensive use of loading/error state, the ability to select which fields you need, etc. But by definition, app data is ubiquitous and simple — usually key-value pairs, or sometimes objects that are needed in various combinations that are read and updated in multiple places in your app. You don’t need to select fields, deal with loading state, etc. Writing queries for these things is simply awkward and excessively verbose, and don’t forget that queries and mutations require separate code. Here’s an example: We had an app for ordering from restaurants. If you leave your table, it should clear incomplete orders and remove the table number you were sitting at. But you shouldn’t be able to do that if you have an unpaid tab (ticket). We had components with render props to compose in the state queries and mutations, and this was a piece of code that appeared in the app: <ClearOrder    render={clearOrder => (      <SetCurrentTable        render={setCurrentTable => (          <GetOrderStatus            render={({ ticketId }) => (              <HeaderButton                label="Leave Table"                disabled={!!ticketId}                onPress={() => {                  clearOrder();                  setCurrentTable({ qrCode: '' });                }}              />            )}          />        )}      />    )}  /> It’s almost enough to make you go back to higher order components! 😱 Actually, I think HOCs would be a good solution here, but composing individual operations is still pretty heavy. Enter Unstated Before we look at Unstated, I should say that you don’t need to use any other state library at all! The is quite nice and may be all you need, allowing you to keep state in a root component. That said, here’s that same component written with new Context API Unstated <Subscribe to={[Table, Order]}>  {(currentTable, order) => (    <HeaderButton      label="Leave Table"      disabled={!!order.state.ticketId}      onPress={() => {        order.clear();        currentTable.set({ qrCode: '' });      }}    />  )}</Subscribe> I find it much more readable, and there are fewer levels of indentation and fewer lines of code. It avoids the pyramid of doom in two ways: Get and set functionality can be shared in one state object, reducing imports. Order and table state could have been combined to one object if we preferred that. We are dealing with classes, so we can combine as many things as we like on that container. There’s a built-in way to subscribe to multiple state containers in one component – the prop takes an array of state objects. Subscribe to Finally, if we compare the code to perform , one of the actions, the difference becomes a little starker: clearOrder The GraphQL is simple enough but doesn’t tell us much: mutation clearOrder {  clearOrder @client} And the resolver ends up looking a lot like a Redux reducer. clearOrder: (_, __, { cache }) => {  const data = cache.readQuery({ query: GET_ORDER });  // make sure you mutate your object correctly  // or other state could be affected  data.items = [];  cache.writeQuery({ query: GET_ORDER, data });  return null; // if you forget to return null, you'll get errors}, The equivalent method in the Unstated class would be a one-liner: // make sure you bind your method if you might pass it// as a propclear = () => this.setState({ items: [] }); Ah, That feels better! Testing with unstated Because Unstated creates an object that is not a react component, you can test it without rendering the component just as you might with Redux: test('clear order', () => {  // instantiate and set up our state object for the test  const orderState = new OrderState();  orderState.setState({ items: ['hamburger'] });  orderState.clear();  expect(orderState.state.items).toEqual({ items: [] });}); Or you can test it in place by injecting it into a component tree with the prop: inject test('clear rendered Orders', () => {  // render an Orders component with the same orderState as above  // (here with react-test-renderer)  const tree = TestRenderer.create(    <Provider inject={[orderState]}>      <Orders />    </Provider>,  );  // make sure our order rendered (1 item)  expect(tree.root.findAllByType(OrderItem).length).toBe(1);  // "press" the leave-table button by calling its onPress, which will  // call our `clear()` method  const leaveTableButton = tree.root.findByProps({    testId: 'leave-table-button',  });  button.props.onPress();  expect(tree.root.findAllByType(OrderItem).length).toBe(0);}); Follow Your Bliss In fact, Unstated is so easy to use, it would be easy to use it for everything, but that’s not really the intent of the library. Use it judiciously, though, and it will fill in a small but very important hole in your state management. Using Unstated in my current project feels like I’ve finally arrived at a complete data solution, and I’m no longer wishing for something different. Originally published at www.okgrow.com .

BLIS

blis.com

-- employees

Since n.d.

COMPANY RANKING

BLIS

EVERGREEN INDEX #1652

Representing this company? Click here to claim and customize this page!

blis WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

BLIS

blis.com

-- employees

Since n.d.

COMPANY RANKING

BLIS

EVERGREEN INDEX #1652

RELATED COMPANIESRANK

STORIES ABOUT BLIS

Representing this company? Click here to claim and customize this page!

blis WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!