759 Matching Annotations
  1. Last 7 days
  2. Dec 2020
    1. React abstracts the DOM with functionally pure declarative rendering and provides escape hatches back to mutable imperative DOM land. This is a profound philosophical difference that Rich gave a talk about.
    2. It's true that Svelte does not allow you to map over children like React, but its slot API and <svelte:component> provide similarly powerful composition. You can pass component constructors as props and instantiate them with <svelte:component>, and use slots and their let bindings for higher order composition. It sounds like you're thinking in virtual DOM idioms instead of Svelte's.
    3. My frustration is mainly from Svelte's choices that are very un-JavaScript-like. It doesn't have to be "like React/Vue". React is React because it doesn't restrict what you can do with JavaScript for the most part. It's just common FP practice to fold/map.
  3. Nov 2020
    1. In this world of digitization, it is essential that you bring your business to the online platforms. The fact is, React Native is one of the most emerging technologies for developing the best application for your business.

      React Native is one of the most emerging technologies for the business. Know how can you hire a React Native developer with less effort.

    1. For use$ since svelte is never going to support actions for components, i designed something that reminds React hooks that will in some ways replace this feature.

      Isn't that what use$ is trying to do already? How is that "something that reminds React hooks" any different? Will be interested to see...

    1. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of it because the tradeoffs are fantastic, to where it'll be a boring talking point before we know it.
    1. Today, more and more businesses are inclined towards react native due to the innumerable benefits it offers. React native apps have completely changed the mobile app development process but the performance of the app remains extraordinary as before.

      In this article, we will be talking about a few popular react native testing tools that will enhance your development process.

  4. Oct 2020
    1. I use a mutator and use it's changeValue function to 'change' the value of the relevant field (I supply the same value). This in turn notifies all relevant parties of the change to the form's state, and a validation is triggered.

      Nearly duplicate annotation here: https://hyp.is/I2t56hjLEeuPXIsZG-jYog/xtzmf.csb.app/

    2. Some user experience issue with the proposed solution: This won't show up the inline field error message if you just hit on submit and other fields already contained errors since the code on the onSubmit won't be hit
    3. This is for a time picker. If you're picking times for today, you may pick a time that is 15 minutes from now. It's valid now because it's currently in the future. If you don't touch the form for the next 20 minutes then click submit, the submission should be prevented because your selected time is now 5 minutes in the past.
    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.

  5. 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.
    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.
  6. 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.