730 Matching Annotations
  1. Last 7 days
    1. Image a situation wherein you have just launched your app. But the data of your app is not being properly displayed or you are not able to fetch the data that is being entered by the users. What will be the impression of your app in the user’s mind?

      Many businesses get confused when it comes to choosing the right database for their application. In fact, it is quite crucial to choose the one between SQLite and Realm.

    1. Presumably this is so that you can import React libraries, even if they depend on ReactDOM, and they will work with Svelte instead.

      Reminds me of Wine. IIRC they have some system calls that they just make to be no-ops on Linux.

  2. react-spectrum.adobe.com react-spectrum.adobe.com
    1. Sometimes you might need to use an element other than a native <button>. useButton supports this via the elementType prop. When used with an element other than a native button, useButton automatically applies the necessary ARIA roles and attributes to ensure that the element is exposed to assistive technology as a button.
  3. Oct 2020
    1. suite of over 30 separate packages of React visualization primitives that fall into several categories (Figure 2). It is un-opinionated on state management, animation, and styling so it can integrate with any React codebase, and its emphasis on modularity (similar to D3) lets you keep your bundle sizes down by only using the packages you need to create your reusable chart library or a custom one-off chart.

      Short definition of visx

    2. In our research (Figure 1), we found that existing React visualization libraries are often high-level abstractions and optimized for ease of use (i.e., fewer lines of code) at the expense of expressivity. None offer the expressivity of D3 primitives and many don’t allow for the optimization we want in production because computation, animations, state management, styles, and rendering are all encapsulated.

      Comparison of data visualisation libraries:

    3. because D3 and React both want to own DOM manipulation, we’ve found that it’s best to only use D3 for the math and React for the DOM because two mental models for updating the DOM opens the door for bugs to sneak in. However, using D3 solely for math means a significant amount of its (DOM-based) functionality is not available for use: selection.join, zoom, drag, brush, and transitions. Additionally, as mentioned above, D3 has its own learning curve and we would like developers to feel like they are writing native React code with standard APIs and familiar patterns.

      You can use D3 inside a React app, but...

    4. Leveraging React and its ecosystem would provide learnability and performance, and a low-level, modular API would deliver expressivity.

      Thanks to React, visx achieved all: learnability, performance and expressivity

    1. You should not create a new debounce function on every render with: return new Promise(resolve => { debounce(() => resolve(this.getIsNameUnique(name)), 2000); }); Instead you should just wrap your whole function isNameUnique with the debounce (see my sandbox). By creating a new debounce function on every hit, it cannot 'remember' that is was called or that is will be called again. This will prevent the debouncing.
    1. In React 0.12 time frame we did a bunch of small changes to how key, ref and defaultProps works. Particularly, they get resolved early on in the React.createElement(...) call. This made sense when everything was classes, but since then, we've introduced function components. Hooks have also make function components more prevalent. It might be time to reevaluate some of those designs to simplify things (at least for function components).
    2. In the next major, we'll start copying the ref onto both the props and the element.ref. React will now use the props.ref as the source of truth for forwardRef and classes and it will still create a shallow copy of props that excludes the ref in these cases. At the same time, we'll add a getter for element.ref in DEV that warns if you access it. The upgrade path is now to just access it off props if you need it from the element.
    3. This proposal simplifies how React.createElement works and ultimately lets us remove the need for forwardRef.
    1. Facebook’s React has an optional language extension that enables you to embed HTML inside JavaScript. This extension can make your code more concise, but it also breaks compatibility with the rest of the JavaScript ecosystem. ECMAScript 6 will have template strings [1], which enable you to implement JSX (or something close to it) inside the language.
    1. Since “virtual DOM” is more of a pattern than a specific technology, people sometimes say it to mean different things. In React world, the term “virtual DOM” is usually associated with React elements since they are the objects representing the user interface
    1. Then at some moment I just stumbled upon limitations and inexpressiveness of templates and started to use JSX everywhere — and because JSX was not a typical thing for Vue I switched to React over time. I don’t want to make a step back.
    2. There is a killer feature of vDOM that Svelte has nothing to replace with. It is the ability to treat component hierarchy as an object.
    1. Typically, unified compilers return string. This compiler returns a ReactElement.
    1. Context can only store a single value, not an indefinite set of values each with its own consumers.
    2. We want to improve this while keeping both the API and the semantics and behavior as Reactish as possible.
    3. Recoil defines a directed graph orthogonal to but also intrinsic and attached to your React tree.
    4. Component state can only be shared by pushing it up to the common ancestor, but this might include a huge tree that then needs to re-render.
    5. For reasons of compatibility and simplicity, it's best to use React's built-in state management capabilities rather than external global state.
    1. You want to write maintainable tests that give you high confidence that your components are working for your users. As a part of this goal, you want your tests to avoid including implementation details so refactors of your components (changes to implementation but not functionality) don't break your tests and slow you and your team down.

      key point. I think that this also means that NOT using data-testid is better since this is "testing library" specific attribute and 'binds' us to testin-library

    1. we are using RTL's findBy search variant to wait for element(s) which appear eventually.

      see above - this is how you'd wait async to grab the element you need

    2. For any element that isn't there yet but will be there eventually, use findBy over getBy or queryBy. If you assert for a missing element, use queryBy. Otherwise default to getBy

      key point: summary of getBy, queryBy and findBy

    3. The neat thing about getByRole: it shows all the selectable roles if you provide a role that isn't available in the rendered component's HTML:

      pass no arguments and it will list all available roles in the element you passed to it (including implicit roles)

    4. // recommended

      notice that this is the recommended practice

    5. Whereas the describe-block is the test suite, the test-block (which also can be named it instead of test) is the test case. A test suite can have multiple test cases and a test case doesn't have to be in a test suite. What you put into the test cases are called assertions (e.g. expect in Jest) which either turn out to be successful (green) or erroneous (red). Here we have two assertions which should turn out successful:

      Key point explaining key basic terms in React testign world

    1. In general it is recommended you handle forms in this "controlled" manner. In some cases it might make sense to manage the form state outside of Solid via refs. These "uncontrolled" forms can also work. Just be conscious of the difference as mixing approaches can lead to unexpected results.
    2. So while Solid's JSX and might resemble React it by no means works like React and there should be no illusions that a JSX library will just work with Solid. Afterall, there are no JSX libraries, as they all work without JSX, only HyperScript or React ones.
    1. Remember even though the syntax is almost identical, there are significant differences between how Solid's JSX works and a library like React.
    1. Solid supports most React features like Fragments, Portals, Context, Suspense, Error Boundaries, Lazy Components, Async Rendering, Implicit Event Delegation, SSR
    1. There's one downside to Reacts reactivity model - the hooks (useState and useEffect) have to always be called in the same order and you can't put them inside an if block.
    2. It's possible to run a function whenever some reactive state changes using the useEffect hook. In the example we log the length of the todoList whenever it changes. The first argument to useEffect is the function we want to run, and the second is a list of reactive values to track - whenever one of these values changes the effect will run again.
    3. MobX - for me personally MobX is a far better way to manage state than React Hooks. It doesn't care about the UI layer so it can be used outside the React ecosystem, and it's simple to mutate data.
    4. derived values are simple to declare
    5. Solid is a declarative JavaScript library for creating user interfaces. It's kinda like if React and Svelte had a baby.
  4. Sep 2020
    1. useField() returns FieldRenderProps. It will manage the rerendering of any component you use it in, i.e. the component will only rerender if the field state subscribed to via useField() changes.
    1. for example, reactive declarations essentially do the work of React's useMemo, useCallback and useEffect without the boilerplate (or indeed the garbage collection overhead of creating inline functions and arrays on each state change).
    1. I think Svelte's approach where it replaces component instances with the component markup is vastly superior to Angular and the other frameworks. It gives the developer more control over what the DOM structure looks like at runtime—which means better performance and fewer CSS headaches, and also allows the developer to create very powerful recursive components.
    1. Since one of Svelte's main principles is reacting only to data changes (as opposed to re-render the whole app with the full state all the time)
    2. Re Object.keys(undefined), I think I'm ok with that failing. AFAIK it would also fail in React
    3. The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)
    1. tip no 8. API should be explicit!

      Optional props (which are not used) make the component less reusable.

      In my opinion, the API of a component should match strictly the values that are used. If the prop is a large object in which only a subset of of properties are used, then it is better to restrict the API to those set of properties.

    1. Like with React, you can pass in callback props like onSave and onDelete, which is the main way you send data out of a component to a parent.
    2. $: declares a relationship, where remaining should always be 10 - count. This might seem weird, but it’s conceptually the same as declaring a variable that you know will be re-calculated in every React render loop — except that remaining will get recalculated only when count changes.
    1. My solution idea is just to let the compiler knows that rest is of type T, using a custom type guard function, but you could use other approaches, like a type casting: <Child {...((rest as unknown) as T)} />
    1. I’ve seen some version of this conversation happen more times than I can remember. And someone will always say ‘it’s because you’re too used to thinking in the old way, you just need to start thinking in hooks’.

      But after seeing a lot of really bad hooks code, I’m starting to think it’s not that simple — that there’s something deeper going on.

    1. With useEffect, you can handle lifecycle events directly inside function components. Namely, three of them: componentDidMount, componentDidUpdate, and componentWillUnmount. All with one function!
    1. In most component frameworks, you need to write some code to define your component. With React, the simplest component is an empty function. In other frameworks, you need to import a library and call a special function to define and create your component. With Svelte, you just create a new .svelte file.

      If you compare these two:

      • With React, the simplest component is an empty function.
      • With Svelte, you just create a new .svelte file.

      Creating a new empty function is actually easier/faster than creating and importing a new file. Because you don't have to create a new file just to create a new one-line component. You can create simple helper components within the same file as the main component they help with, and sometimes it is nice to have the flexibility and freedom to compose your files however you want, including the freedom to group multiple closely related components together in the same file.

      In fact one thing I've sometimes found very useful and handy is to be able to define very simple helper components (functions) within the definition of my main component.

      So I would actually put this comparison in the "win" category for React, not Svelte.

    1. I don't think componentDidRender is a substitute for componentDidMount because the component can render multiple times when props change after it's mounted once.
    2. React is an isomorphic/universal framework. That means that there is a virtual representation of the UI component tree, and that is separate from the actual rendering that it outputs in the browser.
    3. This process of creating instances and DOM nodes corresponding to React components, and inserting them into the DOM, is called mounting.
    1. The previous example contained a default slot, which renders the direct children of a component. Sometimes you will need more control over placement, such as with this <ContactCard>. In those cases, we can use named slots.

      This is a nicer solution than react children props, which is only clean if you pass in a single child.

      The React children prop is an unregulated wild west where people are free to use the prop almost any way they want (including passing in a function).

      I kind of like how Svelte provides a standard, consistent API, which doesn't have the limitations of React childern.

    1. Q7. What are controlled components?In HTML, form elements such as <input>, <textarea>, and <select> typically maintain their own state and update it based on user input. When a user submits a form the values from the aforementioned elements are sent with the form. With React it works differently. The component containing the form will keep track of the value of the input in it's state and will re-render the component each time the callback function e.g. onChange is fired as the state will be updated. A form element whose value is controlled by React in this way is called a "controlled component".With a controlled component, every state mutation will have an associated handler function. This makes it straightforward to modify or validate user input.

      In classical HTML form components such as <input> or <textarea> maintain their own state, which gets sent somewhere upon submission of the form.

      React keeps track of the form's state inside a component and will re-render the component when the state changes. This can be listened to by subscribing to the onChange callback function.

    2. React creates a virtual DOM. When state changes in a component it firstly runs a “diffing” algorithm, which identifies what has changed in the virtual DOM. The second step is reconciliation, where it updates the DOM with the results of diff.The HTML DOM is always tree-structured — which is allowed by the structure of HTML document. The DOM trees are huge nowadays because of large apps. Since we are more and more pushed towards dynamic web apps (Single Page Applications — SPAs), we need to modify the DOM tree incessantly and a lot. And this is a real performance and development pain.The Virtual DOM is an abstraction of the HTML DOM. It is lightweight and detached from the browser-specific implementation details. It is not invented by React but it uses it and provides it for free. ReactElements lives in the virtual DOM. They make the basic nodes here. Once we defined the elements, ReactElements can be render into the "real" DOM.Whenever a ReactComponent is changing the state, diff algorithm in React runs and identifies what has changed. And then it updates the DOM with the results of diff. The point is - it’s done faster than it would be in the regular DOM.

      React creates a virtual DOM and every time the state of a component changes, it runs a diff algorithm on the virtual DOM. If something needs to be changed, it changes only this part in the HTML DOM. This is faster than the default of updating the entire HTML DOM any time something changes.

    3. The state is a data structure that starts with a default value when a Component mounts. It may be mutated across time, mostly as a result of user events.

      The state is a data structure with a default value at the start which can be mutated based on user events.

    4. Q5. What are the differences between a class component and functional component?Class components allows us to use additional features such as local state and lifecycle hooks. Also, to enable our component to have direct access to our store and thus holds state.When our component just receives props and renders them to the page, this is a ‘stateless component’, for which a pure function can be used. These are also called dumb components or presentational components.

      Functional components cannot hold any state, they are stateless.

    1. This is probably one of the biggest things to get used to in React – this flow where data goes out and then back in.
    2. The only difference is that they’re named with camelCase like onClick, onFocus, onDragEnter instead of the all-lowercase names from HTML (onclick, onfocus, ondragenter).
    3. In React, use the ternary operator (?) or a logical AND (&&). The logical AND can cause errors if the variable is not a boolean, so be careful with that one (or just stick with the ternary operator).
  5. Aug 2020
    1. In the two years that I've been working with React professionally, I've never come to a point where I needed to force a re-render. I encourage you to read the article from the beginning if that's what you're here for because usually there's a better way of dealing with React components that aren't updating.
    1. I would shy away from using contexts as your application state. They're intended to be used sparingly. It's likely that some child is changing something in the context and as several items access that context, they're seeing that as a state change they have to care about. I'd highly recommend moving away from contexts as mini-stores and instead focus on how you structure your component tree and the state each one manages.
    1. Merge is a revolutionary technology that lets users import and keep in sync coded React.js components from GIT repositories to the UXPin Editor. Imported components are 100% identical to the components used by developers during the development process. It means that components are going to look, feel and function (interactions, data) just like the real product experienced by the end-users.
  6. Jul 2020
    1. "Lifting State Up" is legitimately the answer to the state management problem in React and it's a rock solid one.

      lifting state up

    2. state more logically separated and located in the react tree closer to where it matters.

      State located closer to where it matters

    3. Sure you can hook up different reducers to manage different parts of your application, but the indirection of going through all these action creators and reducers is not optimal.

      On indirection through multiple action creators and reducers for managing different parts of an application

    4. consistently see developers putting all of their state into redux. Not just global application state, but local state as well. This leads to a lot of problems

      global vs local state management. Solutions are not one size fits all.

    5. One of the reasons redux was so successful was the fact that react-redux solved the prop drilling problem. The fact that you could share data across different parts of your tree by simply passing your component into some magical connect function was wonderful.

      Reasons why redux was so successful

    1. If you have an object of properties, you can 'spread' them on to a component instead of specifying each one: <Info {...pkg}/>
    1. Take the case of the <input> element in this component — we could add an on:input event handler that sets the value of name to event.target.value, but it's a bit... boilerplatey
    1. It’s like skipping a level. For instance: instead of having to pass, say, a “user” to a Layout and have the Layout pass the “user” to the NavBar, you can create a NavBar (with the user already set) and pass the whole thing into Layout. This can help avoid the “prop drilling” problem where you’ve gotta thread a prop down through multiple layers.
    1. One problem—not a fatal one, but still an issue with any virtual DOM—is that embedding SVGs directly into your app can be a resource hog. No matter how much you compress, no matter how logical and streamlined your components, if you need to load up hundreds of very-complex SVGs, React will need to track all of their nodes, and updating them becomes a chore.
    1. Applications built with just React usually have a single root DOM node
    2. Elements are what components are “made of”,