Back to Questions
813
views3
comments
Issues moving to the new UI.Next
websharperdoc elt ui.next upgrade

I'm moving from old Websharper.UI.Next to new Websharper.UI.Next. Which means modifying my code at some points. Today I did a package upgrade in Visual Studio.

I run into the following issues. I hope you have easier or much more intuitive solutions than I created..

1 Incompatible Doc and Elt

I have lots of dynamic controls, which are assemled together with Doc.Concat. All of the individual controls became of type Elt, while Doc.Concact expects a Seq<Doc>. While upgrading I ran into the issue that I provided a Elt list instead of Seq<Doc>. The (ugly) solution is to cast every Elt to Doc whenever I create a dynamic part. Is there a more easy way in the framework?

2 Adding dynamic CSS classes

In the old framework, I could add an Attr.Class to some element, and then add an Attr.ClassDynPred. The whole thing would add up, so pred was true, it would add the dynamic CSS class to the list of classes. Unfortunately, this does not work anymore. If you add attr.class and attr.classdynpred to the same element, it seems that only the attr.classdynpred is working, which also removes the attr.class values. I solved this with a function which adds both together. I did like the old functionality BTW.

.

  • Doc vs Elt: Depending on your code, there are several things you can do to help type inference.

    • If you have a call such as [ ... ] |> Doc.Concat, replacing this with Doc.Concat [ ... ] will allow the list to be properly inferred as being a list<Doc> even if it only contains Elts.

    • If you have a sequence that is first constructed and then later passed to Doc.Concat, then you can specify the type of the sequence once instead of the type of each element:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

      let l =
    [
        p ["a"]
        p ["b"]
        p ["c"]
    ] : list<Doc>
// ...
Doc.Concat l

// instead of:

let l =
    [
        p ["a"] :> Doc
        p ["b"] :> Doc
        p ["c"] :> Doc
    ]

  • Classes: The Attr.Class* and attr.class* families of functions have different semantics. The former adds a class, whereas the latter just sets the class attribute (like all attr.* functions). We are thinking about adding a new attr.* family of functions that would work similarly to Attr.Class*, we're not sure about what to name it yet (suggestions welcome!).

    Aside from the new attr.*, however, you should still be able to use Attr.Class and Attr.DynamicClass to get the same behavior as before.

By on 10/2/2015 9:33 AM ()

Thanks for reply Loïc. The point with casting to List<Doc> is that I had to do it quite a few times. Perhaps a Doc.Concat taking a Elt list would solve it - I can write it myself, but would be nicer in the framework.

As of the Attr.* and attr.*, I assumed that Attr.* would be phased out, because Intellifactory is doing quite a cleanup at the moment; but is this incorrect? I also noticed that there is no attr.empty, while there is a Attr.Empty, that is also a nice one to use together with Attr.ClassDyn. Currently I have no suggestions, but I did like some stuff of the old way of working.

By on 10/2/2015 11:34 AM ()

Having overloaded Doc.Concat for Elt and Doc might work, I will try it out, thanks for the suggestion.

The attr module is basically intended to be the attribute equivalent of what the div, span, etc. functions are for elements: helpers to create nodes with standard HTML names. But the module Attr, just like Doc, will remain for operations like Concat, DynamicClass, Animated, etc.

By on 10/2/2015 11:46 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper