Quick Links

Recent Changes

    1.6.2018 - Compile-check LESS/CSS classnames using TypeScript and Webpack (Changed)

    As I am making myself familiar with modern frontend development based on React, TypeScript, Webpack and others, I learned something really cool. I like to write this down not only for you – dear reader – but also for my own reference.

    The problem

    Let’s say you have a trivial React component like this where you specify a classsName to tell what CSS class should be used:

    const MyComponent = (props: MyComponentProps) => (
    <MySubCompnent className='myclass'>
    ....
    </MySubCompnent>
    );
    
    export default MyComponent;
    

    The problem with this is that we don’t have any compiler-check to ensure this class myclass really exists in our LESS file. So if we have a Typo or we later change the LESS file, we cannot be sure all classes/selectors are still valid. Not even the browser will show that. It silently breaks. Bad thing!

    A solution

    Using Webpack and the LESS loader one can fix this by checking this at compile time. To do so, you can define the style and its classname in the LESS file and import it into .tsx files. The LESS loader for webpack will expose the following LESS variables to the build process where the TypeScript loader (used for the .tsx files) can pick it up.

    MyComponent.less:

    @my-class: ~':local(.myClass)';
     
    @{my-class}{
      width: 100%;
      background-color: green;
    }
    ...
    

    Note the local() function supported by the LESS loader (see webpack config at the end) which scopes that class to a local scope.

    The above LESS files can be typed and imported into the .TSX file like this:

    MyComponent.tsx:

    type TStyles = {
      myClass: string;
    };
     
    const styles: TStyles = require('./MyComponent.less');
     
    const MyComponent = (props: MyComponentProps) => (
     <MySubCompnent className={{styles.myClass}}>
     ....
     </MySubCompnent>
    );
     
    export default MyComponent;
    

    Then firing up your build, the .less file gets picked up using the require() function and checked against the TypeScript type TStyles. The property myClass will contain the LESS/CSS classname as defined in the .less file.

    I then can use the styles.myClass instead of the string literal of the original code.

    To get this working, ensure you have the LESS loader included in your webpack configuration (you probably already have it if your are already using LESS):

    webpack.json:

    module: {
      rules: [
      {
        test: /.tsx?$/,
        loader: "ts-loader"
      },
      {
        test: /.less$/,
        use: ExtractTextPlugin.extract({
        use: [
          {
            loader: "css-loader",
            options: {
              localIdentName: '[local]--[hash:5]',
              sourceMap: true
            }
          }, {
            loader: "less-loader",
            options: {
              sourceMap: true
            }
          }
        ],
        fallback: "style-loader",
        ...
      }),
      ...
    },
    ...
    

    Note: The samples use LESS stylesheets, but one can do the same with SCSS/SASS – I guess. You just have to use another loader for webpack and therefore the syntax supported by that loader.

    No broken CSS classnames anymore – isn’t this cool? Let me know your feedback.

    This is a cross-post from Marc's personal blog at https://marcduerst.com/2018/03/08/compile-check-less-css-classnames-using-typescript-and-webpack/

    31.5.2018 - Quino Roadmap (Changed)

    Quino Roadmap

    This document is about the future of Quino. See the release notes for the past.

    5.1 — June 2018

    • Isolation of Web code to Quino-WebApi
    • Isolation of Windows/Winforms/WPF code to Quino-Windows

    5.2 — July 2018

    • Improvements to the metadata-building API
    • Standardize namespaces, projects and dependencies
    • Move extension methods to components
    • Improve documentation

    6.0 — August 2018

    • Finalize .NET Standard 2.0 support
    • Finalize multi-platform support

    7.0 — Early 2019

    • No features planned yet
    31.5.2018 - Quino Release Notes (Changed)

    The following is a complete list of all Quino release notes, from newest to oldest. See the roadmap for future releases.

    31.5.2018 - v5.0: Bootstrap IOC, authorization driver, improve dependencies (Changed)

    The summary below describes major new features, items of note and breaking changes. The full list of issues is in the release notes below and is available to those with access to the Encodo issue tracker.

    Notes

    Quino 4 was released on 11. August, 2017. Quino 4.1.7 brings that venerable line to a close. Products are encouraged to upgrade to the this version as the next stable build with the improvements outlined below.

    Highlights

    Breaking changes

    • ApplicationBasedTestsBase.CreateApplication() has a new parameter (bool isFixtureApplication). Applications that override this method will have to adjust their definition.
    • PathTools methods are deprecated. In some cases, these methods have been marked as obsolete (true), which causes a compile error. The obsolete message indicates which method to use instead.
    • ICommandSetManager.Apply() no longer has a IValueTools parameter
    • RegisterStandardConnectionServices has been renamed to RegisterApplicationConnectionServices
    • IValueTools.EnumParser is no longer settable; register your object/implementation in the Bootstrap instead
    • Methods from DataMetaExpressionFactoryExtensions has been removed. Instead of creating expressions directly with the expression factory, you should use the query or query table.
    • IQueryCondition no longer has a type parameter (it used to be IQueryCondition<TSelf>)
    31.5.2018 - v4.1.7: Winform bug fixes and resources captions for modules (Changed)

    The summary below describes major new features, items of note and breaking changes. The full list of issues is in the release notes and is available to those with access to the Encodo issue tracker.

    Highlights

    • Fixed Custom Controls in Winform Navigation (QNO-5889)
    • Use Resource Captions for all standard modules (QNO-5883, QNO-5884)

    Note

    Unless we find a blocking issue that can't be fixed with a patch to the product, this will be the last release on the 4.x branch.

    Breaking changes

    • IExternalLoggerFactory has been renamed to IExternalLoggerProvider
    • ExternalLoggerFactory has been renamed to ExternalLoggerProvider
    • NullExternalLoggerFactory has been renamed to NullExternalLoggerProvider
    • IUserCredentials.AuthenticationToken is now an IToken instead of a string
    31.5.2018 - Finding deep assembly dependencies (Changed)

    Quino contains a Sandbox in the main solution that lets us test a lot of the Quino subsystems in real-world conditions. The Sandbox has several application targets:

    • WPF
    • Winform
    • Remote Data Server
    • WebAPI Server
    • Console

    The targets that connect directly to a database (e.g. WPF, Winform) were using the PostgreSql driver by default. I wanted to configure all Sandbox applications to be easily configurable to run with SqlServer.

    Just add the driver, right?

    This is pretty straightforward for a Quino application. The driver can be selected directly in the application (directly linking the corresponding assembly) or it can be configured externally.

    Naturally, if the Sandbox loads the driver from configuration, some mechanism still has to make sure that the required data-driver assemblies are available.

    The PostgreSql driver was in the output folder. This was expected, since that driver works. The SqlServer was not in the output folder. This was also expected, since that driver had never been used.

    I checked the direct dependencies of the Sandbox Winform application, but it didn't include the PostgreSql driver. That's not really good, as I would like both SqlServer and PostgreSql to be configured in the same way. As it stood, though, I would be referencing SqlServer directly and PostgreSql would continue to show up by magic.

    Before doing anything else, I was going to have to find out why PostgreSql was included in the output folder.

    I needed to figure out assembly dependencies.

    Visual Studio?

    My natural inclination was to reach for NDepend, but I thought maybe I'd see what the other tools have to offer first.

    Does Visual Studio include anything that might help? The "Project Dependencies" shows only assemblies on which a project is dependent. I wanted to find assemblies that were dependent on PostgreSql. I have the Enterprise version of Visual Studio and I seem to recall an "Architecture" menu, but I discovered that these tools are no longer installed by default.

    According to the VS support team in that link, you have to install the "Visual Studio extension development" workload in the Visual Studio installer. In this package, the "Architecture and analysis tools" feature is available, but not included by default.

    Hovering this feature shows a tooltip indicating that it contains "Code Map, Live Dependency Validation and Code Clone detection". The "Live Dependency Validation" sounds like it might do what I want, but it also sounds quite heavyweight and somewhat intrusive, as described in this blog from the end of 2016. Instead of further modifying my VS installation (and possibly slowing it down), I decided to try another tool.

    ReSharper?

    What about ReSharper? For a while now, it's included project-dependency graphs and hierarchies. Try as I might, I couldn't get the tools to show me the transitive dependency on PostgreSql that Sandbox Winform was pulling in from somewhere. The hierarchy view is live and quick, but it doesn't show all transitive usages.

    The graph view is nicely rendered, but shows dependencies by default instead of dependencies and usages. At any rate, the Sandbox wasn't showing up as a transitive user of PostgreSql.

    I didn't believe ReSharper at this point because something was causing the data driver to be copied to the output folder.

    NDepend to the rescue

    So, as expected, I turned to NDepend. I took a few seconds to run an analysis and then right-clicked the PostgreSql data-driver project to select NDepend => Select Assemblies... => That are Using Me (Directly or Indirectly) to show the following query and results.

    Bingo. Sandbox.Model is indirectly referencing the PostgreSql data driver, via a transitive-dependency chain of 4 assemblies. Can I see which assemblies they are? Of course I can: this kind of information is best shown on a graph, so you can show a graph of any query results by clicking "Export to Graph" to show the graph below.

    Now I can finally see that the SandboxModel pulls in the Quino.Testing.Models.Generated (to use the BaseTypes module) which, in turn, has a reference to Quino.Tests.Base which, of course, includes the PostgreSql driver because that's the default testing driver for Quino tests.

    Now that I know how the reference is coming in, I can fix the problem. Here I'm on my own: I have to solve this problem without NDepend. But at least NDepend was able to show me exactly what I have to fix (unlike VS or ReSharper).

    I ended up moving the test-fixture base classes from Quino.Testing.Models.Generated into a new assembly called Quino.Testing.Models.Fixtures. The latter assembly still depends on Quino.Tests.Base and thus the PostgreSql data driver, but it's now possible to reference the Quino testing models without transitively referencing the PostgreSql data driver.

    A quick re-analysis with NDepend and I can see that the same query now shows a clean view: only testing code and testing assemblies reference the PostgreSql driver.

    Finishing up

    And now to finish my original task! I ran the Winform Sandbox application with the PostgreSql driver configured and was greeted with an error message that the driver could not be loaded. I now had parity between PostgreSql and SqlServer.

    The fix? Obviously, make sure that the drivers are available by referencing them directly from any Sandbox application that needs to connect to a database. This was the obvious solution from the beginning, but we had to quickly fix a problem with dependencies first. Why? Because we hate hacking. :-)

    Two quick references added, a build and I was able to connect to both SQL Server and PostgreSql.

    15.3.2018 - C# Handbook 7.0 (Changed)

    The focus of this document is on providing a reference for writing C#. It includes naming, structural and formatting conventions as well as best practices for writing clean, safe and maintainable code. Many of the best practices and conventions apply equally well to other languages.

    15.3.2018 - Location map (Changed)

    A map of the Encodo office in Winterthur and surrounding areas.

    15.3.2018 - Metadata in Software Development (Changed)

    A short introduction to the use of metadata in software development.

    15.3.2018 - Introduction to Munjari (Changed)

    Munjari provides tools that will allow almost anyone to put their ideas online. This non-technical introduction is a great place to learn more.

    15.3.2018 - Brochure (Changed)

    A summary of Encodo and its services.