joffrey-bion / livedoc

A not-so-annotation-based documentation generator for REST and websocket services
MIT License
5 stars 2 forks source link

Livedoc UI fails to display types #104

Closed jpeffer closed 6 years ago

jpeffer commented 6 years ago

Navigating to the livedocs Types screen produces a list of known types. An exception however occurs within the client when attempting to view information regarding a type and instead produces a blank screen. The exception produced is shown below:

livedoc types exception

joffrey-bion commented 6 years ago

@jpeffer Thanks for opening this issue.

I cannot reproduce this issue using Livedoc 4.4.1 and the sample app. Does this happen with every type, or is it just for one of them? If just one, could you please provide the class? If you are not allowed to share this code, please provide an MCVE to help me reproduce.

Maybe you can try to clean your local storage for the domain of the doc. Since v4.4.1, you should not be able to load the doc from the local storage nor to fetch it from an URL if there is a version mismatch between Livedoc UI and the data. However, if you just moved to v4.4.1 from an older version, you might want to give a try (one last time :D).

Thanks again!

jpeffer commented 6 years ago

Yep it happens with all types. Looking at the error in Chrome, it gives a slightly move useful error:

react-dom.production.min.js:164 TypeError: Cannot read property 'length' of undefined
    at i (TypeFieldRow.jsx:25)
    at beginWork (react-dom.production.min.js:132)
    at a (react-dom.production.min.js:161)
    at i (react-dom.production.min.js:161)
    at s (react-dom.production.min.js:162)
    at E (react-dom.production.min.js:169)
    at _ (react-dom.production.min.js:168)
    at batchedUpdates (react-dom.production.min.js:171)
    at J (react-dom.production.min.js:54)
    at Pe (react-dom.production.min.js:71)

Could this have something to do with my object mapper? My object mapper is excluding non_empty fields:


<bean id="livedocObjectMapper" class="org.springframework.http.converter.json.Jackson2ObjectMapperFactoryBean"
          p:mixIns-ref="jacksonMixins"
          p:featuresToDisable-ref="disabledJacksonFeatures"
          p:serializationInclusion="NON_EMPTY" />

<util:list id="disabledJacksonFeatures" value-type="com.fasterxml.jackson.databind.MapperFeature">
    <util:constant static-field="com.fasterxml.jackson.databind.SerializationFeature.WRITE_DATES_AS_TIMESTAMPS" />
</util:list>

I imagine if this is the cause, it relates to the Flow Issue #103 .

joffrey-bion commented 6 years ago

Thanks for sharing this information. This error looks different from the first one you posted first.

You're spot on! This is due to your ObjectMapper removing fields that are empty arrays. I didn't realize that a custom ObjectMapper would affect the output of /jsondoc as well.

It looks like the missing property here is the list of format constraints on a type's property. However, looking at the code, the list cannot be undefined and should at worse be empty. But your custom ObjectMapper takes it away because it's empty, thus creating the issue you see.

This is also very likely to cause the flows issue, as you pointed out.

joffrey-bion commented 6 years ago

A quick fix for you would be to remove this setting on your ObjectMapper, at least temporarily.

As far as a long term solution is concerned, I opened a parent issue for both the flows issue and this one, in order to track the more general problem: https://github.com/joffrey-bion/livedoc/issues/106. I'm therefore closing this issue in favor of that one.

As a side discussion, may I ask why you use this setting? I find it quite different to have an empty list VS a missing list. I can understand people removing null fields from the JSON, as it yields the same results when parsing it on the other end, and it simply means the field is optional. However, it is different for something to provide an empty list or no list at all. The absence of list could trigger a fallback to a default list, while an empty list could explicitly mean that no elements should be considered. Also, empty lists are a great way to avoid dealing with special cases.