102 Matching Annotations
  1. Jun 2021
    1. We should test for events emitted in response to an action in our component. This is used to verify the correct events are being fired with the correct arguments.
  2. May 2021
  3. Apr 2021
    1. the commonality of clicks, buttons, and even the icon with three horizontal lines now apparently means “menu” to everyone.

      And yet I hate this pattern

  4. Mar 2021
    1. But I believe the core philosophy of tiny modules is actually sound and easier to maintain than giant frameworks.
    2. "Functions Are Not Packages" - Well why not?
    3. Small modules are extremely versatile and easy to compose together in an app with any number of other modules that suit your needs.
    4. Write modules that are small. Iterate quickly.
  5. Feb 2021
  6. Dec 2020
  7. Nov 2020
    1. Finally, you gain the ability to reuse previously built packets for new projects. Maybe some research you did for an online marketing campaign becomes useful for a new campaign. Or some sketches that didn’t quite make it into an old design give you inspiration for a new one. Or some book notes you wrote down casually turn out to be very useful for an unforeseen challenge a year later.

      The Intermediate Packet approach allows you to reuse previously built packets for new projects

      By incorporating existing packets in new projects, you gain the ability to deliver new projects much faster.

  8. Oct 2020
    1. Industrialization: You can easily chop your form validations into smaller independent pieces that can be developed by separate teams in paralell with no dependencies.
    1. One of Svelte's advantages, for me, is that I can test out ideas with relatively few lines of code. the #with feature could save me from adding a separate component for the content of an #each loop. I get frustrated when I have to create a new file, move the content of the #each clause, import it as a component, and add attributes and create exports for that, and implement events to send messages back, and event handlers, when I just wanted to test a small feature.
    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).
    1. inline components, await...then, and each blocks are the exact use case where I want this.
    2. We are very close to full inline components (with css, js logic, and templates).
    3. Taking all three of today's proposals (#32 #33 #34) together it would become theoretically possible to make an entire application in a single file which is the complete opposite direction of what Svelte has been so far.

      That wouldn't be so bad, to have that flexibility...

      It would give the power that is available in JSX (like inline anonymous components), to Svelte, which those coming from JSX would appreciate.

    4. Since re-rendering in Svelte happens at a more granular level than the component, there is no artificial pressure to create smaller components than would be naturally desirable
    5. are much better to read and write as inline anonymous templates, not components
    1. When I say that my experience is that it means it's time to split up your components, I guess I mean that there tends to be a logical grouping between all the things that care about (for example) sqr_n, and in Svelte, logical groupings are expressed as components.
    1. When using React hooks there is no concept of onMount because the idea of only running some code on mount leads to writing non-resilient components, components that do one thing when they mount, and then don’t take prop changes into account.
    1. Especially when coming from a framework like React, it might feel very tempting to start creating a component wrapper around the input (i.e. <input> becomes <Input/>) and add your custom event handlers in there.This is a great approach in React, but not so much in Svelte. Why, you ask?Well, Svelte (at least in its current form, v3) really shines when you have native DOM elements at your disposal. You can use transition directives, conditionally switch CSS classes, bind to the current value with ease, and more.
  9. Sep 2020
    1. Many people recently are complaining about bundler performance. But I don’t think any tool is going to solve performance problems. Bundlers can try innovative ideas such as multi-threading and improved caching, but you’re always going to hit a limit. If you’re having performance problems, it’s more likely because you’re not keeping tabs of what you’re importing, and haven’t considered splitting your project into multiple projects.
    1. Developing software is usually easier if you break your project into smaller separate pieces, since that often removes unexpected interactions and dramatically reduces the complexity of the problems you'll need to solve
    1. We don't want to rely on there being a single root element - or prevent ourselves from ever implementing named slots without a single root node - and so there's not anything to apply the class to or the transition to.
    2. I think instead, there would need to be some special way to make the distinction of what is a slot attribute and what is a slot prop to be consumed with let:. Maybe a new directive like <slot attr:class="abc"/>?
    1. There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
    2. The main reason using classes isn't a great solution is that it completely breaks encapsulation in a confusing way, the paren't shouldn't be dictating anything, the component itself should. The parent can pass things and the child can choose to use them or not but that is different: control is still in the hands of the component itself, not an arbitrary parent.
    3. The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
    1. the notion that any given component should be in charge of its own thing, and not do something outside of itself. I.e., loosely coupled components in a sandbox, not tightly coupled to something outside of its own scope.
    1. Since re-rendering in Svelte happens at a more granular level than the component, there is no artificial pressure to create smaller components than would be naturally desirable, and in fact (because one-component-per-file) there is pressure in the opposite direction. As such, large components are not uncommon.
    1. In my projects on Svelte, we adhere to the "budget" of the component in 200 loc with styles. If the component goes these limits, we just take out styles in a separate file using svelte-preprocess.
    1. In some frameworks, a module can contain multiple components, some of which need not be exported (and are therefore effectively private). In Svelte, there is a strict one-component-per-file rule. This is nice and simple to understand and explain (not to mention implement), but it does have drawbacks. Users sometimes complain that it causes a proliferation of .svelte files, many of which contain very simple components that would be better declared inline.
    1. I'm personally surprised about that, given the degree to which web component advocates prioritise encapsulation — it seems like a footgun, honestly
    2. Personally, I think class is too blunt an instrument — it breaks encapsulation, allowing component consumers to change styles that they probably shouldn't, while also denying them a predictable interface for targeting individual styles, or setting theme properties globally
    3. ...but ultimately the component itself has control over what is exposed, and can specify its own fallback values using normal CSS custom property syntax:
    1. A component should be in complete control of itself. Not only should a component's styles not leak out but other component's style should never leak in. Consider this 'Encapsulation part 2' if you will. When writing a component, you have certain guarantees that not only will the styles you write be contained within the component, but nothing from the outside should affect you either. You have a certain confidence that if it works in isolation, then it will continue to work when embedded within a complex application.
    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.

  10. Aug 2020
  11. Jun 2020
    1. Note that when you use &::before with content, you need to add quotes to the value of content, otherwise the text does not get applied correctly.

      &:hover{ background-color: ${props => lighten(0.7,themesMap.get(props.theme)!.secondaryColor)}; } &:before{ content: 'before'; }

  12. Apr 2020
    1. The major effect of steroids is to inhibit the inflammatory phase of wound healing (angiogenesis, neutrophil and macrophage migration, and fibroblast proliferation) and the release of lysosomal enzymes
    2. An effective therapy to combat biofilm should include effective removal of the biofilm, antimicrobial eradication of bacteria/organisms, and prevention of biofilm recurrence, and these treatment options may need to be repeated multiple times to achieve effective therapy.
  13. Dec 2019
  14. Nov 2019
    1. it’s important to embrace pedagogies that leverage synchronous (live) instruction.

      It is mention in this article that Arizona State University is on the right track regarding superior online services. this article point of view is about the online challenges for colleges and universities, such as, doing live videos, online services and supplying tech devices. this website "EdTech" is a online magazine education technology resource for both K-12 and higher education.

  15. Oct 2019
    1. Inner RefSome components are passed an innerRef property to facilitate for internally managed behaviour within the base select. This should be assigned to the ref property of the relevant dom element. i.e.const CustomOptionComponent = ({ innerProps, innerRef }) => (<div ref={innerRef} {...innerProps} />) Inner PropsAll functional properties that the component needs are provided in innerProps which you must spread.
  16. Sep 2019
  17. Aug 2019
    1. I propose to developphonetic discrimination in mice as a model for speech perception. I will thendirectly testthe predictions made by competing neurolinguisticmodels

      End your introduction with a one-sentence description of your project. Use italics to make in-paragraph text easy for your reviewer to pick out.

    1. Customization of the TextField can be cumbersome with the classes API, where you have to define the the classes prop. It's easier to use the default values, as described above. For example:

      It's surprising that they show an example using styled-components, which is a competing style library to their own @material-ui/styles, and even admit that this might be preferred over using the classes API, which they admit may be cumbersome.

      I like that they are open-minded enough to acknowledge that there are cases where built-in API may be too cumbersome, and even show examples of using styled-components.

  18. Nov 2018
    1. OnClick

      the OnClick feature is as now not available. the contextual menu activate an URL on click as per Syncfusion component standard. We'll try to develop an advanced action to override this feature but it's not working out of the box.

      https://ej2.syncfusion.com/documentation/context-menu/api-contextMenu.html?lang=typescript#items

  19. Sep 2018
  20. Jun 2018
    1. News stories also contain at least one of the following important characteristics relative to the intended audience: proximity, prominence, timeliness, human interest, oddity, or consequence.
  21. Mar 2017
  22. Jan 2017
    1. Component classes should be lean. They don't fetch data from the server, validate user input, or log directly to the console. They delegate such tasks to services.

      A really good point! Lean-ness is something to strive for.

    2. While a component is technically a directive, components are so distinctive and central to Angular applications that this architectural overview separates components from directives.

      As per the MVVM pattern, they sort of provide the support for the View. They are like the glue for the visual representation of a part of the application. A controller of sorts (but not quite one) of MVC.

    1. selector: 'admin-users'

      Why isn't this selector defined as toh-admin-users, just like above toh-hero suggestion?

  23. Aug 2016
  24. Apr 2016
    1. This is a pretty good summary of the recent evolution of front-end architecture, described in a framework-independent way.

  25. Jan 2016
    1. UI components for ElasticsearchThe easiest way to build a great search experience with Elasticsearch.

      UI components for Elasticsearch

  26. Sep 2015
    1. This is an interesting dive into the challenges of creating a good language to describe the structure and functionality of a UI.

      It advocates using a declarative structure to lay out the components and then using imperative logic within the components.

  27. Jan 2014
    1. H o w t o R e a d O p i n i o n s

      This section on how to read judicial opinions helpfully describes the components of what an opinion contains and some discussion of the challenges in identifying those components within the structure of the opinion.

      The components identified here are:

      • caption/name of parties
      • name of the court
      • date of the opinion
      • date of oral arguments in appellate cases
      • citation information
      • name of judge(s) who wrote the opinion
      • case history
      • procedural posture (stage at which opinion was issued)
      • information about facts of the case (especially for trial court opinions)
      • statement of legal issues involved
      • the holding (decision about the issues)
      • the judge's reasoning