text: import { useRef } from 'react'
  import Head from 'next/head';
  import { faFileChartLine } from '@fortawesome/pro-solid-svg-icons';
  import DocPage from '../../components/DocPage'
  import DocSection from '../../components/DocSection'
  
  export default function Tutorials() {
    const toc =
    [
      { id: "ms", title: "File guidelines – module vs static method", ref: useRef(null) } ,
      { id: "ps", title: "File guidelines – plural vs singular", ref: useRef(null) } ,
      { id: "ng", title: "Namespace guidelines – Logary.Internals or not", ref: useRef(null) } ,
      { id: "ril", title: "RuntimeInfo and internal logging", ref: useRef(null) } ,
      { id: "wwnf", title: "When to write a new function?", ref: useRef(null) } ,
      { id: "fg", title: "File guidelines – module vs static method", ref: useRef(null) } ,
      { id: "fg", title: "File guidelines – module vs static method", ref: useRef(null) } ,
      { id: "fg", title: "File guidelines – module vs static method", ref: useRef(null) } ,
    ]
  
    return (
      <DocPage name="js-quickstart" title="Tutorials" faIcon={faFileChartLine} colour="primary" readingMinutes={3} toc={toc}>
        <Head>
          <title key="title">Tutorials</title>
        </Head>
        Clone it like above. Ensure you can build it. Open <span className="_code"> Logary.sln </span>. Make a change, send a PR towards master. To balance the app.config files, try <span className="_code"> mono tools/paket.exe install --redirects --clean-redirects --createnewbindingfiles</span>
        <DocSection {...toc[0]}>
          <h2 className="section-title">File guidelines – module vs static method</h2>
          <p></p>
          <p>Declare your interfaces in a <span className="_code"> MyIf.fs </span> and its module in <span className="_code"> MyIfModule.fs </span> with a ([CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)])).</p>
          <p>Place these files as high as possible. Place the module as close to and below the non-module file as possible.</p>
          <p>If it's plausible that one would like to use point-free programming with your functions, place them in a module. (E.g. Message versus MessageModule)</p>
          <p>Factory methods go on the types for value types. For stateful objects they go on the module, named <span className="_code"> create </span> which may or may not return a <span className="_code"> Job[] </span> of some public state type with a private/internal constructor. (E.g. PointName versus Engine)</p>
        </DocSection>
        <DocSection {...toc[1]}>
          <h2 className="section-title">File guidelines – plural vs singular</h2>
          <p></p>
          <p>All implementations go in a plural namespace. E.g. <span className="_code"> Logary.Metrics.Ticked </span> has:</p>
          <ul>
            <li><span className="_code">Logary</span> – core namespace</li>
            <li><span className="_code">Metrics</span> – namespace for all metrics implementations</li>
            <li><span className="_code">Ticked</span> – a module and/or type that implements Logary-based ticking/ scheduling.</li>
          </ul>
          <p>Another example: <span className="_code"> Logary.Target </span>, which is a module that implements logic about the life-cycle of target instances. It's used to start/stop/pause and shutdown targets. It's singular.</p>
        </DocSection>
        <DocSection {...toc[2]}>
          <h2 className="section-title">Namespace guidelines – <span className="_code"> Logary.Internals </span>or not</h2>
          <p></p>
          <p>Things that end-users of the library are not likely to configure should go in <span className="_code">Logary.Internals</span> . Examples include <span className="_code"> Logary.Internals.Globals </span> and <span className="_code"> Logary.Internals.RuntimeInfo </span> (which is configured with the config API instead).</p>
        </DocSection>
        <DocSection {...toc[3]}>
          <h2 className="section-title">RuntimeInfo and internal logging</h2>
          <p></p>
          <p>The <span className="_code"> RuntimeInfo </span> and internal <span className="_code"> Logger </span> should be propagated to the modules and objects that you build your solution out of. This guideline is mostly about the registry's implementation and its interaction with config and services.</p>
        </DocSection>
        <DocSection {...toc[4]}>
          <h2 className="section-title">When to write a new function?</h2>
          <p></p>
          <p>Generally, keep your functions to a single responsibility and compose functions instead of extending existing functions. Composition happens through currying and partial application of 'state' or 'always-this-value' values. For state it can both go through the Services abstraction (start/pause/stop/etc) or by closing over the state with a function.</p>
          <p>If you find that your functions are getting larger than 3 lines of code, you should probably extract part of the function. By 'default' it's better to be 1% less performant but 5% more readable, after this list of priorities:</p>
          <ol type="1">
            <li>Correct</li>
            <li>CReadable/SRPorrect</li>
            <li>Fast/efficient/performant</li>
          </ol>
        </DocSection>
      </DocPage>
    )
  }